Is giadinh.edu.vn Safe? Security Score 74.7/100 | CyStack
giadinh.edu.vn
TRƯỜNG ĐẠI HỌC GIA ĐỊNH
Trường Đại học Gia Định là một trong những cơ sở giáo dục uy tín hàng đầu tại Việt Nam, đào tạo đa ngành với cam kết mang đến cơ hội thực tập và việc làm cho sinh viên sau khi tốt nghiệp.
Industry
Science and Education / Education
Origin
Vietnam
Global rank
#544,485
Rank in Vietnam
#9,928
Updated at
C74.7/100
Security level
Fair
Data confidence
High
Scope checked
97.3%
The higher the score, the more externally observable protections the system has recorded. This page does not certify that the website is reputable, legitimate, or completely free of vulnerabilities.
Is the website “giadinh.edu.vn” safe?
As of July 23, 2026 at 09:43, giadinh.edu.vn has a security score of 74.7/100 (grade C – “Fair”). CyStack’s automated assessment recorded 16 issues to review after completing 97.3% of applicable checks. The website owner should address “Known-exploited CVE candidates” first, then review the remaining items in order of impact.
Does giadinh.edu.vn show known scam, phishing, or malware signals?
At assessment time, CyStack did not find giadinh.edu.vn or related infrastructure on any scam, phishing, or malware warning list after checking 5 online reputation sources. This result reflects external observations; it does not guarantee absolute safety or verify the organization’s legal status or reputation.
Compare the security level of each assessed category at a glance.
Network attack surface95.5/100 · Good100% of this category was checked
Web security31.3/100 · High risk100% of this category was checked
Frequently asked questions
What affects the security of giadinh.edu.vn?
A valid SSL certificate still does not prove that giadinh.edu.vn is safe, legitimate, or free of scam signals. For a more complete assessment, this report also checks phishing and malware, exposed email records, IPs and open ports, subdomains, technologies, and CVEs that may apply to observed versions.
Does giadinh.edu.vn use HTTPS, and is its SSL certificate valid?
giadinh.edu.vn used a valid SSL certificate at assessment time, valid until October 7, 2026. This status may change when the certificate expires or the server configuration changes.
Have @giadinh.edu.vn email addresses appeared in exposed data or information-stealer (infostealer) logs?
Data sources
Data compiled from CyStack cybersecurity monitoring systems
CyStack compiles scan results from its internal cybersecurity monitoring systems, including CyStack VulnScan and CyStack Threat Intelligence, together with publicly available Internet data. The assessment only observes and analyzes information already available; it does not attempt unauthorized access, test passwords, send exploit code, or change or disrupt the assessed system.
There are 3 issues to prioritize because they have the greatest impact on the security of giadinh.edu.vn.
Known-exploited CVE candidatesFound 2 known-exploited candidate(s), but the external product fingerprint requires verification.Critical
Check result
Found 2 known-exploited candidate(s), but the external product fingerprint requires verification.
Why it matters
A possible CVE match also appears in the CISA Known Exploited Vulnerabilities (KEV) catalog, which means attackers have used that vulnerability in real incidents. The match is urgent to investigate, but the installed software still needs to be confirmed as affected.
What to do
Verify the installed product immediately and follow the CISA and vendor instructions for mitigation, patching, or upgrading if it is affected.
Session cookies protected from scripts (HttpOnly)This check found a security issue.High
Check result
This check found a security issue.
Why it matters
HttpOnly prevents browser scripts from directly reading a cookie. It does not fix script injection, but it makes theft of session and authentication cookies more difficult.
What to do
Set HttpOnly on session and authentication cookies unless the application has a documented need to read them in browser code.
Cookies sent only over HTTPS (Secure)This check found a security issue.High
Check result
This check found a security issue.
Why it matters
The Secure attribute prevents a browser from sending a cookie over unencrypted HTTP. Without it, session or authentication data may be exposed to someone observing the network.
What to do
Set Secure on every session, authentication, and other sensitive cookie served by the HTTPS application.
Transport encryption
78.4/100 · Fair
100% of this category was checked
Threat reputation100/100 · Good100% of this category was checked
Vulnerability and technology risk57.1/100 · Review100% of this category was checked
Email authentication100/100 · Good100% of this category was checked
Data exposure50/100 · Review100% of this category was checked
Domain and DNS hygiene90/100 · Good55.6% of this category was checked
Issues to review
The complete list of issues to review, including the three priorities highlighted in the summary.
Found 2 known-exploited candidate(s), but the external product fingerprint requires verification.
Why it matters
A possible CVE match also appears in the CISA Known Exploited Vulnerabilities (KEV) catalog, which means attackers have used that vulnerability in real incidents. The match is urgent to investigate, but the installed software still needs to be confirmed as affected.
What to do
Verify the installed product immediately and follow the CISA and vendor instructions for mitigation, patching, or upgrading if it is affected.
Session cookies protected from scripts (HttpOnly)Website protectionFailed
Check result
This check found a security issue.
Why it matters
HttpOnly prevents browser scripts from directly reading a cookie. It does not fix script injection, but it makes theft of session and authentication cookies more difficult.
What to do
Cookies sent only over HTTPS (Secure)Website protectionFailed
Check result
This check found a security issue.
Why it matters
The Secure attribute prevents a browser from sending a cookie over unencrypted HTTP. Without it, session or authentication data may be exposed to someone observing the network.
What to do
Set Secure on every session, authentication, and other sensitive cookie served by the HTTPS application.
Content Security Policy (CSP) limits where scripts, styles, frames, and other browser content may come from. A strong policy reduces the impact if an attacker manages to inject content into a page.
What to do
Define only the sources the application needs, test the policy before activating it, and avoid broad wildcard (*) rules, unsafe-inline, and unsafe-eval where possible.
Supported TLS versionsHTTPS and encryptionFailed
Check result
Accepted versions: TLS 1.0, TLS 1.1, TLS 1.2.
Why it matters
TLS 1.0 and TLS 1.1 use outdated security designs and are no longer accepted by modern standards. Leaving them enabled allows older, weaker connection methods.
What to do
Disable TLS 1.0 and TLS 1.1, support TLS 1.2 securely, and enable TLS 1.3 where possible.
Potential CVEs for observed versionsSoftware vulnerabilitiesNeeds review
Check result
Found 153 potentially applicable CVE candidate(s), including 82 high or critical candidate(s).
Why it matters
The detected product and version were compared with vulnerability records from the National Vulnerability Database (NVD). A match is a lead, not confirmation: the installed software may include vendor fixes or may differ from the version visible on the Internet.
Domain registration expiryDomain and DNSUnknown
Check result
The scan did not collect enough evidence for a reliable conclusion.
Why it matters
An expired domain stops directing users to the organization's services and may eventually become available to someone else. A domain close to expiry leaves little time to recover from payment or account problems.
What to do
Renew well before the expiry date, enable automatic renewal, and protect the payment method and registrar account.
Domain registration statusDomain and DNSUnknown
Check result
The scan did not collect enough evidence for a reliable conclusion.
Why it matters
Registrar or registry restrictions such as hold, redemption, or pending deletion can disable the domain. If they are not resolved, the organization may lose control of its website and email identity.
What to do
Resolve registration restrictions promptly, protect the registrar account with MFA, and keep ownership and contact information current.
Protection from deceptive framing (clickjacking)Website protectionFailed
Check result
This check found a security issue.
Why it matters
Another website can place this page inside a hidden or misleading frame and trick a user into clicking an unintended action. Frame restrictions tell browsers which sites, if any, may embed the page.
Without the nosniff setting, a browser may guess a file's type and treat harmless-looking content as executable code. This can turn an incorrect Content-Type into a security issue.
What to do
Send X-Content-Type-Options: nosniff on every response and return an accurate Content-Type.
HSTS availabilityHTTPS and encryptionFailed
Check result
The HTTPS response does not contain an effective HSTS policy.
Why it matters
HTTP Strict Transport Security (HSTS) tells a browser to use HTTPS automatically on future visits. This reduces the chance that a visitor is downgraded to an unencrypted connection.
What to do
After confirming that every required page works over HTTPS, send the Strict-Transport-Security header on all HTTPS responses.
CyStack confirmed at least 74 active DNS subdomains. 3 names may expose sensitive services; discovery was partial, so more may exist.
Why it matters
Names containing admin, development, staging, VPN, database, or monitoring terms may point attackers toward valuable systems. A name alone does not prove exposure, but it identifies a surface that should be reviewed.
17 email exposure records have an identity domain exactly matching this target and are associated with approximately 13 infected devices. These are intelligence observations; they do not prove that the email accounts are still active or that the devices belong to the organization.
Why it matters
Infostealer intelligence may contain credentials associated with the domain, but it does not prove that an account is current, valid, or still exposed.
Permissions-Policy controls whether this page and embedded content may use features such as the camera, microphone, and location. Leaving unused features available creates unnecessary access paths.
When a visitor follows a link, the browser may send the previous page's URL to the destination. Paths and query values in that URL can reveal sensitive context to another website.
What to do
Use strict-origin-when-cross-origin or a stricter Referrer-Policy, and avoid placing secrets in URLs.
Exact web server or framework versions help attackers quickly look for known weaknesses that may apply. Hiding a version is not a substitute for patching, but unnecessary disclosure gives away useful targeting information.
What to do
Allowed certificate issuers (CAA)Domain and DNSNeeds review
Check result
Found 0 applicable CAA record(s).
Why it matters
Certificate Authority Authorization (CAA) records state which certificate providers may issue certificates for the domain. This reduces the chance of an unintended provider issuing one.
What to do
Publish CAA records that allow only the certificate providers your organization actually uses.
DNS response protection (DNSSEC)Domain and DNSNeeds review
Check result
No DNSSEC DS delegation was found.
Why it matters
DNSSEC adds digital signatures so resolvers can detect forged DNS answers. This quick check confirms the parent domain has a DS record, but it does not validate the complete signature chain.
What to do
Sign the DNS zone, publish the matching DS record through the registrar, and monitor the signature chain after key changes.
Other evaluated controls (34)
Certificate matches the websiteHTTPS and encryption
Check result
The certificate matches the requested target.
Why it matters
The certificate must list the exact hostname visitors requested in its Subject Alternative Names (SAN). A mismatch produces browser warnings because the certificate may belong to a different service.
What to do
Issue and deploy a certificate whose SAN list includes every public hostname served by this website address.
Data recorded by the system
Certificate domain names:
*.giadinh.edu.vn, giadinh.edu.vn
Assessed domain:
giadinh.edu.vn
Browser-trusted certificateHTTPS and encryption
Check result
The certificate chains to a trusted root.
Why it matters
Browsers trust a website only when its certificate can be traced to a recognized certificate provider. An untrusted certificate causes warnings and prevents visitors from reliably confirming the website's identity.
What to do
Install a certificate from a provider trusted by common browsers and configure the server to send every required intermediate certificate.
Data recorded by the system
Certificate issuer:
CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
Secure website connection (HTTPS)HTTPS and encryption
Check result
A TLS handshake succeeded on port 443.
Why it matters
HTTPS encrypts data between visitors and the website and helps prove they reached the intended service. Without it, network observers may read or alter traffic and browsers may show a security warning.
What to do
Provide the entire website over HTTPS using a certificate trusted by common browsers.
Data recorded by the system
Encryption suite:
TLS ECDHE RSA WITH AES 128 GCM SHA256
IP address:
42.116.157.117
Version:
TLS 1.2
Public DNS recordsDomain and DNS
Check result
The target resolved to 1 public IP address(es).
Why it matters
Public DNS connects the domain to its Internet addresses. Missing or incorrect records can make the service unreachable or send traffic to the wrong system.
What to do
Make sure the domain resolves only to its intended public IP addresses, and remove private, reserved, or outdated records.
Data recorded by the system
IP addresses:
42.116.157.117
Password form transport securityWebsite protectionNot applicable
Check result
This check does not apply to the target.
Why it matters
If either a password page or the address receiving its form uses HTTP, someone observing the network may read or change the submitted password.
What to do
Serve every page containing a password field over HTTPS and submit each password form directly to an HTTPS address.
Data recorded by the system
Password forms:
0
Public management service exposurePublic infrastructure
Check result
No public management service was found on the scanned TCP port set.
Why it matters
Remote administration services such as RDP, VNC, Docker, Kubernetes, and management consoles are high-value targets. Public exposure allows anyone on the Internet to attempt passwords or exploit an unpatched service.
What to do
Remove direct Internet access and require a VPN, a hardened access gateway, or trusted source networks; also use MFA where supported.
Data recorded by the system
Complete:
Yes
Fingerprint Complete:
Yes
Fingerprint Identified:
2
Fingerprint Targets:
2
Database or cache exposed to the InternetPublic infrastructure
Check result
No public datastore service was found on the scanned TCP port set.
Why it matters
Databases and caches often contain sensitive information and are normally used only by internal applications. Direct Internet access makes password attacks and configuration mistakes much more likely to become a data breach.
What to do
Listen only on private interfaces, allow connections only from required application systems, and require strong authentication and encryption.
Data recorded by the system
Complete:
Yes
Fingerprint Complete:
Yes
Fingerprint Identified:
2
Fingerprint Targets:
2
File-sharing service exposed to the InternetPublic infrastructure
Check result
No public file-sharing service was found on the scanned TCP port set.
Why it matters
Services such as SMB, NFS, and rsync can reveal or modify shared files and have a history of serious vulnerabilities. They rarely need to accept connections directly from the public Internet.
What to do
Limit file-sharing services to private networks or a tightly controlled VPN, and allow only the users and systems that require access.
Data recorded by the system
Complete:
Yes
Fingerprint Complete:
Yes
Fingerprint Identified:
2
Fingerprint Targets:
2
Unencrypted legacy servicePublic infrastructure
Check result
No public legacy cleartext service was found on the scanned TCP port set.
Why it matters
Older services such as Telnet, FTP, and unencrypted mail or directory protocols can send passwords and data in readable form. Anyone able to observe the network path may capture them.
What to do
Disable the legacy service or replace it with an encrypted alternative such as SSH, SFTP, HTTPS, or the secure version of the mail protocol.
Data recorded by the system
Complete:
Yes
Fingerprint Complete:
Yes
Fingerprint Identified:
2
Fingerprint Targets:
2
Cross-site access rules (CORS)Website protection
Check result
No issue was found by this check.
Why it matters
Cross-Origin Resource Sharing (CORS) decides which websites may read responses from this service in a visitor's browser. Rules that trust arbitrary origins, especially with login cookies, can expose private data to another website.
What to do
Allow only explicitly trusted websites, compare the Origin value with an exact approved list, and never allow login credentials with the wildcard origin (*).
Data recorded by the system
Arbitrary origin accepted:
No
Credentials allowed:
No
Allows all origins:
No
Certificate expiry and validityHTTPS and encryption
Check result
The certificate is valid from 2025-10-06T00:00:00Z to 2026-10-06T23:59:59Z.
Why it matters
A certificate works only between its start and expiry dates. An expired, not-yet-valid, or soon-to-expire certificate can trigger browser warnings and interrupt access to the website or API.
What to do
Use automatic renewal, monitor renewal failures, and alert the responsible team well before expiry.
Data recorded by the system
Days remaining:
75.9
Expires at:
Valid from:
Certificate key and signature strengthHTTPS and encryption
Check result
The certificate uses SHA256-RSA with a 2048-bit public key.
Why it matters
The certificate's public key and signature algorithm protect it from forgery. Keys that are too short or signatures based on obsolete algorithms provide less protection against modern attacks.
What to do
Use RSA with at least 2048 bits or a modern elliptic-curve key, and use SHA-256 or a stronger signature algorithm.
Data recorded by the system
Public-key algorithm:
RSA
Public-key size:
2,048
Signature algorithm:
SHA256-RSA
DNS abuse-list reputationIP reputation
Check result
No independent abuse-list consensus was found across 5 definitive providers.
Why it matters
Security and email providers maintain DNS-based blacklists of IP addresses associated with spam, malware, or compromised systems. Several current, independent listings are a strong reason to investigate, although a shared IP can sometimes affect unrelated customers.
What to do
Verify each listing against the affected IP, investigate mail and host activity, fix the underlying cause, and then follow the provider's removal process.
Data recorded by the system
Blocklists with no match:
5
Confirmed blocklist matches:
No
Blocklists checked conclusively:
5
Blocklists unavailable:
1
DMARC blocking policyEmail protection
Check result
The effective DMARC policy is reject.
Why it matters
A policy of quarantine or reject tells receiving services to move suspicious mail to spam or refuse it. A monitoring-only policy (p=none) records the problem but does not ask receivers to stop spoofed mail.
What to do
After every legitimate sender passes DMARC, move gradually to quarantine and then reject, covering 100% of messages.
Data recorded by the system
Declared policy:
reject
Effective policy:
reject
DMARC policy setting:
p
Test mode:
No
References
Email spoofing protection (DMARC)Email protection
Check result
A DMARC policy was found.
Why it matters
DMARC lets the domain owner tell receiving services what to do when the visible From address is not verified by SPF or DKIM. Without DMARC, attackers have more opportunity to impersonate the domain in phishing email.
What to do
Publish a DMARC record at _dmarc, begin by collecting reports, and confirm that legitimate senders pass before applying a blocking policy.
The core DMARC policy tags passed structural validation.
Why it matters
Receiving services may ignore a DMARC record that contains duplicate fields, invalid values, or is published at the wrong DNS name. An ignored record provides no reliable protection from domain impersonation.
What to do
Publish one valid DMARC record at _dmarc and correct duplicate fields, unsupported values, and invalid report addresses.
SameSite limits when a browser includes cookies in requests started by another website. This helps prevent another site from silently making an authenticated request on a user's behalf.
What to do
Use SameSite=Lax or Strict by default. Use SameSite=None only for a required cross-site flow and always combine it with Secure.
Data recorded by the system
Cookies missing SameSite:
0
SameSite=None cookies missing Secure:
0
Total:
1
Insecure content on an HTTPS pageWebsite protection
Check result
No issue was found by this check.
Why it matters
An HTTPS page can still load scripts, frames, styles, or forms over unencrypted HTTP. An attacker on the network may alter that content and compromise the otherwise secure page.
What to do
Load every script, frame, stylesheet, and form destination over HTTPS, and remove or replace resources that do not support it.
Data recorded by the system
Insecure page resources:
0
Complete certificate chainHTTPS and encryption
Check result
The server presented 3 certificate(s).
Why it matters
The server must provide the intermediate certificates that connect its website certificate to a trusted provider. If any are missing, some browsers, mobile devices, or API clients may reject the connection.
What to do
Configure the server to send the website certificate followed by every required intermediate certificate, but not the root certificate.
Data recorded by the system
Certificates in the chain:
3
Automatic redirect to HTTPSHTTPS and encryption
Check result
The HTTP root redirects to HTTPS within the target domain.
Why it matters
Visitors may enter an address beginning with HTTP or follow an old link. Redirecting them immediately to HTTPS prevents the rest of the visit from continuing over an unencrypted connection.
What to do
Redirect every HTTP URL directly to its corresponding HTTPS URL without passing through another HTTP address.
Data recorded by the system
Final connection:
https
Website reachable:
Yes
Redirects followed:
1
Public directory listingSoftware vulnerabilities
Check result
The root page did not match a common automatic directory-index pattern.
Why it matters
When a web server automatically lists a directory, visitors may discover files that were never linked publicly, including backups, logs, or deployment artifacts.
What to do
Disable automatic directory indexes unless public file browsing is an intentional feature, and remove sensitive files from web-accessible folders.
Data recorded by the system
Directory listing pattern found:
No
Homepage only:
Yes
SPF protection levelEmail protection
Check result
The terminal SPF policy is -all.
Why it matters
The final SPF rule tells receiving services how confidently they should reject unlisted senders. A permissive result allows more spoofed mail to appear legitimate than a hard fail (-all).
What to do
Confirm that every legitimate sender is included, then end the SPF record with -all.
Sender Policy Framework (SPF) lists the systems allowed to send email for the domain. Without it, receiving services have less evidence to distinguish legitimate mail from spoofed mail.
What to do
Publish one SPF TXT record that includes every legitimate email service and no unauthorized sender.
More than one SPF record, invalid terms, or too many DNS lookups can make SPF return a permanent error. Receiving services may then be unable to verify authorized senders.
What to do
Keep one valid SPF record, remove invalid terms, and remain within the SPF limit of ten DNS-based lookups.
MX records direct incoming email to the correct mail servers. Broken records can stop delivery, while a Null MX clearly tells senders that the domain does not receive email.
What to do
Correct unreachable or outdated MX hosts, or publish a Null MX if the domain is not intended to receive email.
Data recorded by the system
Does not receive email:
No
Unnecessary public servicesPublic infrastructure
Check result
No public unexpected service was found on the scanned TCP port set.
Why it matters
Every open service can be discovered and attacked and must be configured, monitored, and patched. Services without a clear public purpose add risk without providing business value.
What to do
Confirm the owner and purpose of every open port, then stop or firewall any service that is not intentionally public.
Data recorded by the system
Complete:
Yes
Fingerprint Complete:
Yes
Fingerprint Identified:
2
Fingerprint Targets:
2
DMARC monitoring reportsEmail protection
Check result
Aggregate reporting is configured.
Why it matters
DMARC aggregate reports show which systems send email using the domain and which messages fail verification. They help find both impersonation attempts and legitimate services that need correction.
What to do
Add an aggregate report address (rua) that is protected and monitored, or use a trusted DMARC reporting service.
A domain should clearly state whether it receives email. Without valid MX records or a Null MX, senders may try an unintended server and delivery behavior becomes unpredictable.
What to do
Publish valid MX records for the intended mail servers, or a Null MX if the domain never accepts email.
Data recorded by the system
Does not receive email:
No
DNS service redundancyDomain and DNS
Check result
Found 3 authoritative name server(s).
Why it matters
Authoritative name servers tell visitors where the domain is hosted. Depending on only one server creates a single point of failure for the website and email.
What to do
Use at least two authoritative name servers, preferably on independent and resilient infrastructure.
HSTS protection periodHTTPS and encryptionNot applicable
Check result
This check does not apply to the target.
Why it matters
The max-age value controls how long browsers remember to use HTTPS. A very short period provides limited protection, while includeSubDomains also covers every subdomain and can break one that does not support HTTPS.
What to do
Use a long max-age, and add includeSubDomains only after confirming that every active subdomain works correctly over HTTPS.
Blacklist check coverageIP reputationInformation
Check result
5 providers were definitive and 1 were inconclusive.
Why it matters
This shows how many independent blacklist services returned a clear result. A service that was unavailable was not checked successfully and must not be treated as a clean result.
Data recorded by the system
Blocklists with no match:
5
Confirmed blocklist matches:
No
Blocklists checked conclusively:
5
Blocklists unavailable:
1
Technologies visible from the InternetSoftware vulnerabilitiesInformation
Check result
Public signals from the website and its open services revealed 11 technology item(s).
Why it matters
Response headers, page content, and other public clues suggest which technologies the service uses. These observations help explain the attack surface, but they can be incomplete or mistaken and do not by themselves confirm a vulnerability.
Data recorded by the system
Technologies found:
11
Detection method:
Website and exposed-service analysis
Root Response Count:
11
Service Inventory Complete:
Observed WAF, CDN, or edge serviceSoftware vulnerabilitiesInformation
Check result
No WAF, CDN, or edge product matched the passive root-response signals; this does not prove that protection is absent.
Why it matters
Public response details suggest that a Web Application Firewall (WAF), CDN, or other edge service is present. This quick scan identified the provider but did not test whether attack blocking is configured or working correctly.
Observed 5 versioned product(s); 3 had exact CPE mappings and 3 completed lookup(s).
Why it matters
This shows how many detected products had reliable version information and an exact CPE identity, allowing them to be checked against CVE applicability data. A product that could not be checked must not be treated as free of known vulnerabilities.
Potentially exposed domain email addressesChecks infostealer data only for email addresses whose domain exactly matches this target. A record is not counted merely because someone visited or signed in to this website.17 Matching email exposure records
17Matching email exposure records
13Related infected devices (estimated)
These matching email records were observed previously, but they may already have been addressed or may no longer be valid. The device count estimates infected devices associated with these email records; it is not the number of devices owned by the organization.
Leak evidenceMost recent observation:
Email addressRelated infected deviceInfection evidenceRecorded time
Email addressl*****@giadinh.edu.vnRelated infected deviceJ**** (Windows 11 Home Single Language)IndiaIOC reference: IOC-4AE6491539
At most 10 recent redacted records are shown to protect sensitive information.
Discovered subdomains (74+)Subdomains discovered by CyStack, with sensitive-looking names shown first. Availability is verified during this assessment; individual subdomains have not been separately security-tested.Partial
Public web contextThe website title, description, industry and popularity.
Page title
TRƯỜNG ĐẠI HỌC GIA ĐỊNH
Website category
Science and Education / Education
Description
Trường Đại học Gia Định là một trong những cơ sở giáo dục uy tín hàng đầu tại Việt Nam, đào tạo đa ngành với cam kết mang đến cơ hội thực tập và việc làm cho sinh viên sau khi tốt nghiệp.
Global rank
#544,485
Rank in Vietnam
#9,928
Rank in industry
#593
This is a quick, point-in-time check from outside the organization. It can surface visible risks, but it does not replace penetration testing or an authenticated assessment.
There are currently 17 exposed email records matching the giadinh.edu.vn domain. These records may be old or already resolved. The website owner should verify them before resetting passwords or locking related accounts.
Which public IPs, services, and ports does giadinh.edu.vn expose?
The assessment observed 1 public IPs and 2 open ports for giadinh.edu.vn; the infrastructure appears to be operated by FPT Telecom Company. An open port is not automatically a vulnerability, but every public service should be updated and appropriately restricted.
How many subdomains of giadinh.edu.vn have been discovered?
The assessment observed 74+ public subdomains of giadinh.edu.vn. This list can reveal additional entry points such as APIs, administration systems, or test environments, but it does not mean that every subdomain is risky.
Confirm the exact installed package and read the vendor advisory. If that installation is affected, apply the vendor patch or upgrade to a fixed version.
Remove obsolete DNS names and protect non-public systems with strong authentication, MFA, network allowlists, or a VPN.
Data recorded by the system
Data available:
Yes
Complete:
No
List shortened:
No
Sensitive:
3
Total:
74
Total is a minimum count:
Yes
What to do
Review the masked evidence and observation time, validate affected accounts and devices, then reset active credentials and sessions, enforce MFA, and remove malware where confirmed.
Data recorded by the system
Distinct affected devices observed:
13
Estimated infostealer-infected devices:
13
Evidence Mask Policy:
Length Preserving V2
Evidence samples shown:
10
Evidence sample limit:
10
Evidence samples available:
Yes
More evidence samples exist:
Yes
Matching exposed email records:
17
How exposed email records are matched:
Only email addresses whose domain exactly matches this website
Most recently observed:
Allow each sensitive browser feature only for the pages and trusted origins that require it, and disable the rest.
Email addressv***@giadinh.edu.vnRelated infected deviceA******* (Windows 10 Pro)VietnamIOC reference: IOC-5A4F52DB88Infection evidenceVidarObserved application: Microsoft Edge (Default)Recorded time
Email addressd*****@giadinh.edu.vnRelated infected deviceNo safely shareable device details are available for this record.VietnamIOC reference: IOC-59BFBDB785Infection evidenceLummaObserved application: Edge Default (129.0.2792.65)Recorded time
Email addresst******@giadinh.edu.vnRelated infected deviceNo safely shareable device details are available for this record.VietnamIOC reference: IOC-E5D247CF54Infection evidenceLummaObserved application: Chrome Default (129.0.6668.71)Recorded time
Email addressN*****************@giadinh.edu.vnRelated infected deviceD************** (Windows 11 Home (10.0.26100) x64)IOC reference: IOC-45DCE0C114Infection evidenceLummaObserved application: Chrome Default (138.0.7204.184)Recorded time
Email addressl******************@giadinh.edu.vnRelated infected deviceM********* (Windows 11 Home Single Language (10.0.22631) x64)IOC reference: IOC-C08665E694Infection evidenceLummaObserved application: Chrome Profile 4 (136.0.7103.93)Recorded time
Email addressN**************@giadinh.edu.vnRelated infected deviceNo safely shareable device details are available for this record.IOC reference: IOC-5E7C8EDB3BInfection evidenceCS.Stealer.SatanicRecorded time
Email addressl****@giadinh.edu.vnRelated infected deviceNo safely shareable device details are available for this record.IOC reference: IOC-5E7C8EDB3BInfection evidenceCS.Stealer.SatanicRecorded time
Email addressB*************@giadinh.edu.vnRelated infected deviceA**** (Windows 10 Pro x64)VietnamIOC reference: IOC-C83A46A3B4Infection evidenceStealCObserved application: Google ChromeRecorded time
Email addresss***@giadinh.edu.vnRelated infected deviceW********* (Windows 10 Pro (10.0.19045) x64)VietnamIOC reference: IOC-B9F0814AC0Infection evidenceLummaObserved application: Chrome Default (127.0.6533.120)Application has administrator privilegesRecorded time
Website rankings and industry category are based on data from Similarweb
CVE-2024-38475HTTPD 2.4.6KEVCVSS 9.1
Matched product: HTTPD 2.4.6 Confidence: High
Improper escaping of output in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to map URLs to filesystem locations that are permitted to be served by the server but are not intentionally/directly reachable by any URL, resulting in code execution or source code disclosure.
Substitutions in server context that use a backreferences or variables as the first segment of the substitution are affected. Some unsafe RewiteRules will be broken by this change and the rewrite flag "UnsafePrefixStat" can be used to opt back in once ensuring the substitution is appropriately constrained.
A crafted request uri-path can cause mod_proxy to forward the request to an origin server choosen by the remote user. This issue affects Apache HTTP Server 2.4.48 and earlier.
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication phase may lead to authentication requirements being bypassed.
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime can read one byte past the end of a buffer when sending a malicious Content-Type response header.
In Apache httpd 2.2.0 to 2.4.29, when generating an HTTP Digest authentication challenge, the nonce sent to prevent reply attacks was not correctly generated using a pseudo-random seed. In a cluster of servers using a common Digest authentication configuration, HTTP requests could be replayed across servers by an attacker without detection.
ap_escape_quotes() may write beyond the end of a buffer when given malicious input. No included modules pass untrusted data to these functions, but third-party / external modules may. This issue affects Apache HTTP Server 2.4.48 and earlier.
A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser (r:parsebody() called from Lua scripts). The Apache httpd team is not aware of an exploit for the vulnerabilty though it might be possible to craft one. This issue affects Apache HTTP Server 2.4.51 and earlier.
Apache HTTP Server 2.4.52 and earlier fails to close inbound connection when errors are encountered discarding the request body, exposing the server to HTTP Request Smuggling
Out-of-bounds Write vulnerability in mod_sed of Apache HTTP Server allows an attacker to overwrite heap memory with possibly attacker provided data. This issue affects Apache HTTP Server 2.4 version 2.4.52 and prior versions.
Apache HTTP Server 2.4.53 and earlier may not send the X-Forwarded-* headers to the origin server based on client side Connection header hop-by-hop mechanism. This may be used to bypass IP based authentication on the origin server/application.
Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack.
Configurations are affected when mod_proxy is enabled along with some form of RewriteRule
or ProxyPassMatch in which a non-specific pattern matches
some portion of the user-supplied request-target (URL) data and is then
re-inserted into the proxied request-target using variable
substitution. For example, something like:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
Request splitting/smuggling could result in bypass of access controls in the proxy server, proxying unintended URLs to existing origin servers, and cache poisoning. Users are recommended to update to at least version 2.4.56 of Apache HTTP Server.
Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts in
directories permitted by the configuration but not directly reachable by any URL or source disclosure of scripts meant to only to be executed as CGI.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Some RewriteRules that capture and substitute unsafely will now fail unless rewrite flag "UnsafeAllow3F" is specified.
Vulnerability in core of Apache HTTP Server 2.4.59 and earlier are vulnerably to information disclosure, SSRF or local script execution via backend applications whose response headers are malicious or exploitable.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Heap-based Buffer Overflow vulnerability in mod_proxy_ajp of Apache HTTP Server.
If mod_proxy_ajp connects to a malicious AJP server this AJP server can send a malicious AJP message back to mod_proxy_ajp and cause it to write 4 attacker controlled bytes after the end of a heap based buffer.
This issue affects Apache HTTP Server: through 2.4.66.
Users are recommended to upgrade to version 2.4.67, which fixes the issue.
Use After Free vulnerability in Apache HTTP Server with mod_ldap in per-directory configuration
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.
Users are recommended to upgrade to version 2.4.68, which fixes the issue.
Buffer Underwrite vulnerability in Apache HTTP Server on crafted regular expressions in the configuration.
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.
Users are recommended to upgrade to version 2.4.68, which fixes the issue.
In Apache httpd before 2.2.34 and 2.4.x before 2.4.27, the value placeholder in [Proxy-]Authorization headers of type 'Digest' was not initialized or reset before or between successive key=value assignments by mod_auth_digest. Providing an initial key with no '=' assignment could reflect the stale value of uninitialized pool memory used by the prior request, leading to leakage of potentially confidential information, and a segfault in other cases resulting in denial of service.
If LimitXMLRequestBody is set to allow request bodies larger than 350MB (defaults to 1M) on 32 bit systems an integer overflow happens which later causes out of bounds writes. This issue affects Apache HTTP Server 2.4.52 and earlier.
Apache HTTP Server 2.4.53 and earlier may crash or disclose information due to a read beyond bounds in ap_strcmp_match() when provided with an extremely large input buffer. While no code distributed with the server can be coerced into such a call, third-party modules or lua scripts that use ap_strcmp_match() may hypothetically be affected.
A path handling issue in mod_dav_fs in Apache 2.4.67 and earlier allows a WebDAV content author to directly manipulate trusted DAV property databases, potentially causing child process crashes.
Users are recommended to upgrade to version 2.4.68, which fixes this issue.
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.54 and prior versions.
An escalation of privilege bug in various modules in Apache HTTP 2.4.66 and earlier allows local .htaccess authors to read files with the privileges of the httpd user.
Users are recommended to upgrade to version 2.4.67, which fixes this issue.
Apache HTTP Server 2.4.65 and earlier with Server Side Includes (SSI) enabled and mod_cgid (but not mod_cgi) passes the shell-escaped query string to #exec cmd="..." directives.
This issue affects Apache HTTP Server before 2.4.66.
Users are recommended to upgrade to version 2.4.66, which fixes the issue.
In Apache httpd 2.4.0 to 2.4.29, the expression specified in <FilesMatch> could match '$' to a newline character in a malicious filename, rather than matching only the end of the filename. This could be exploited in environments where uploads of some files are are externally blocked, but only by matching the trailing portion of the filename.
The zend_string_extend function in Zend/zend_string.h in PHP through 7.1.5 does not prevent changes to string objects that result in a negative length, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact by leveraging a script's use of .= with a long string.
The Keccak XKCP SHA-3 reference implementation before fdc6fef has an integer overflow and resultant buffer overflow that allows attackers to execute arbitrary code or eliminate expected cryptographic properties. This occurs in the sponge function interface.
A command inject vulnerability allows an attacker to perform command injection on Windows applications that indirectly depend on the CreateProcess function when the specific conditions are satisfied.
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the vulnerability enables network and same-site attackers to set a standard insecure cookie in the victim's browser which is treated as a `__Host-` or `__Secure-` cookie by PHP applications.
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress "quines" gzip files, resulting in an infinite loop.
In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.* before 8.3.8, due to a code logic error, filtering functions such as filter_var when validating URLs (FILTER_VALIDATE_URL) for certain types of URLs the function will result in invalid user information (username + password part of URLs) being treated as valid user information. This may lead to the downstream code accepting invalid URLs as valid and parsing them incorrectly.
OpenSSL is a software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end.
Issue summary: A specially crafted PKCS#7 or S/MIME signed message could
trigger a use-after-free during PKCS#7 signature verification.
Impact summary: A use-after-free may result in process crashes, heap
corruption, or potentially remote code execution.
When processing a PKCS#7 or S/MIME signed message, if the SignedData
digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may
incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent
use of the BIO by the calling application results in a use-after-free
condition.
In the common case this occurs when the application later calls
BIO_free() on the BIO originally passed to PKCS7_verify(). Depending
on allocator behavior and application-specific BIO usage patterns, this
may result in a crash or other memory corruption. In some application
contexts this may potentially be exploitable for remote code execution.
Applications that process PKCS#7 or S/MIME signed messages using OpenSSL
PKCS#7 APIs may be affected. Applications using the CMS APIs for this
processing are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: A signed integer overflow when sizing the destination
buffer for Unicode output in ASN1_mbstring_ncopy() can lead to a heap
buffer overflow.
Impact summary: A heap buffer overflow may lead to a crash or possibly
attacker controlled code execution or other undefined behaviour.
In ASN1_mbstring_copy() and ASN1_mbstring_ncopy() the destination
size for Unicode output is computed in a signed int: by left shift
of the input character count for BMPSTRING (UTF-16) and
UNIVERSALSTRING (UTF-32), and by summing per-character byte counts
for UTF8STRING. The calculation overflows when the input reaches
around 2^30 characters. In the worst case (UNIVERSALSTRING at 2^30
characters) the size wraps to zero, OPENSSL_malloc(1) is called, and
the subsequent character copy writes several gigabytes past the
one-byte allocation.
X.509 certificate processing routes through ASN1_STRING_set_by_NID(),
whose DIRSTRING_TYPE mask excludes UNIVERSALSTRING and whose per-NID
size limits cap the input length; no network protocol or
certificate-handling path in OpenSSL exercises the overflow.
Triggering the bug requires an application that calls
ASN1_mbstring_copy() or ASN1_mbstring_ncopy() directly, or registers
a custom string type via ASN1_STRING_TABLE_add(), with
attacker-controlled input on the order of half a gigabyte or more.
For these reasons this issue was assigned Low severity.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by
this issue, as the affected code is outside the OpenSSL FIPS module
boundary.
During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2-1.0.2o).
Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
CVE-2023-0215openssl 1.0.2kCVSS 7.5
Matched product: openssl 1.0.2k Confidence: High
The public API function BIO_new_NDEF is a helper function used for streaming
ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the
SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by
end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter
BIO onto the front of it to form a BIO chain, and then returns the new head of
the BIO chain to the caller. Under certain conditions, for example if a CMS
recipient public key is invalid, the new filter BIO is freed and the function
returns a NULL result indicating a failure. However, in this case, the BIO chain
is not properly cleaned up and the BIO passed by the caller still retains
internal pointers to the previously freed filter BIO. If the caller then goes on
to call BIO_pop() on the BIO then a use-after-free will occur. This will most
likely result in a crash.
This scenario occurs directly in the internal function B64_write_ASN1() which
may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on
the BIO. This internal function is in turn called by the public API functions
PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream,
SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7.
Other public API functions that may be impacted by this include
i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and
i2d_PKCS7_bio_stream.
The OpenSSL cms and smime command line applications are similarly affected.
A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints. Attackers may be able to exploit this
vulnerability by creating a malicious certificate chain that triggers
exponential use of computational resources, leading to a denial-of-service
(DoS) attack on affected systems.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer
dereference in the PKCS12_item_decrypt_d2i_ex() function.
Impact summary: A NULL pointer dereference can trigger a crash which leads to
Denial of Service for an application processing PKCS#12 files.
The PKCS12_item_decrypt_d2i_ex() function does not check whether the oct
parameter is NULL before dereferencing it. When called from
PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can
be NULL, causing a crash. The vulnerability is limited to Denial of Service
and cannot be escalated to achieve code execution or memory disclosure.
Exploiting this issue requires an attacker to provide a malformed PKCS#12 file
to an application that processes it. For that reason the issue was assessed as
Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Issue summary: When a delta CRL that contains a Delta CRL Indicator extension
is processed a NULL pointer dereference might happen if the required CRL
Number extension is missing.
Impact summary: A NULL pointer dereference can trigger a crash which
leads to a Denial of Service for an application.
When CRL processing and delta CRL processing is enabled during X.509
certificate verification, the delta CRL processing does not check
whether the CRL Number extension is NULL before dereferencing it.
When a malformed delta CRL file is being processed, this parameter
can be NULL, causing a NULL pointer dereference.
Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in
the verification context, the certificate being verified to contain a
freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and
an attacker to provide a malformed CRL to an application that processes it.
The vulnerability is limited to Denial of Service and cannot be escalated to
achieve code execution or memory disclosure. For that reason the issue was
assessed as Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: During processing of a crafted CMS EnvelopedData message
with KeyAgreeRecipientInfo a NULL pointer dereference can happen.
Impact summary: Applications that process attacker-controlled CMS data may
crash before authentication or cryptographic operations occur resulting in
Denial of Service.
When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is
processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier
is examined without checking for its presence. This results in a NULL
pointer dereference if the field is missing.
Applications and services that call CMS_decrypt() on untrusted input
(e.g., S/MIME processing or CMS-based protocols) are vulnerable.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: During processing of a crafted CMS EnvelopedData message
with KeyTransportRecipientInfo a NULL pointer dereference can happen.
Impact summary: Applications that process attacker-controlled CMS data may
crash before authentication or cryptographic operations occur resulting in
Denial of Service.
When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with
RSA-OAEP encryption is processed, the optional parameters field of
RSA-OAEP SourceFunc algorithm identifier is examined without checking
for its presence. This results in a NULL pointer dereference if the field
is missing.
Applications and services that call CMS_decrypt() on untrusted input
(e.g., S/MIME processing or CMS-based protocols) are vulnerable.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: Parsing a crafted DER-encoded ASN.1 structure with a primitive
element whose content exceeds 2 gigabytes in length may cause a heap buffer
over-read on 64-bit Unix and Unix-like platforms.
Impact summary: The heap buffer over-read may crash the application (Denial of
Service) or to load into the decoded ASN.1 object contents of memory beyond the
end of the input buffer. More typically such ASN.1 elements would instead be
truncated.
An integer truncation in OpenSSL's ASN.1 decoder causes the content length of
an ASN.1 primitive element to be mishandled when it exceeds 2 gigabytes. In the
worst case the truncated length is treated as a request to scan the binary
content for a terminating zero byte, possibly causing OpenSSL to read either
less than or beyond the end of the allocated buffer.
Applications that pass attacker-supplied data to d2i_X509(), d2i_PKCS7(), or
any other d2i_* decoding function are affected. OpenSSL's own command-line
tools are not vulnerable, as data read through the BIO layer is checked before
it reaches the affected code. The issue only affects 64-bit Unix and Unix-like
platforms; 32-bit platforms and 64-bit Windows are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by this issue,
as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap)
processes attacker-supplied CMS data, an attacker-chosen stream-mode KEK
cipher can trigger a heap out-of-bounds read in kek_unwrap_key().
Impact summary: A heap buffer over-read may trigger a crash which leads to
Denial of Service for an application if the input buffer ends at a memory
page boundary and the following page is unmapped. There is no information
disclosure as the over-read bytes are not revealed to the attacker.
The key unwrapping function performs a check-byte test as specified in the
RFC that reads 7 bytes from a heap allocation that is based on the wrapped
key length from the message. There is a minimum length check based on the
block length of the wrapping cipher. However the cipher is selected from
an OID carried in the attacker's PWRI keyEncryptionAlgorithm with no
requirement that the cipher be a block cipher. When an attacker selects
a stream-mode cipher the guard will be ineffective and the allocated buffer
containing the unwrapped key can be too small to fit the check-bytes
specified in the RFC and a buffer over-read can happen.
Applications calling CMS_decrypt() or CMS_decrypt_set1_password()
(equivalently openssl cms -decrypt -pwri_password ...) on untrusted CMS
data are vulnerable to this issue. No password knowledge is required: the
over-read happens during the unwrap attempt before any authentication
succeeds.
The over-read is limited to a few bytes and is not written to output, so
there is no information disclosure. Triggering a crash requires the
allocation to border unmapped memory, which is unlikely with the normal
allocator.
The FIPS modules are not affected by this issue.
ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
CVE-2023-0286openssl 1.0.2kCVSS 7.4
Matched product: openssl 1.0.2k Confidence: High
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but
the public structure definition for GENERAL_NAME incorrectly specified the type
of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by
the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an
ASN1_STRING.
When CRL checking is enabled (i.e. the application sets the
X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass
arbitrary pointers to a memcmp call, enabling them to read memory contents or
enact a denial of service. In most cases, the attack requires the attacker to
provide both the certificate chain and CRL, neither of which need to have a
valid signature. If the attacker only controls one of these inputs, the other
input must already contain an X.400 address as a CRL distribution point, which
is uncommon. As such, this vulnerability is most likely to only affect
applications which have implemented their own functionality for retrieving CRLs
over a network.
The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd).
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze).
There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.
Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe. Fixed in OpenSSL 1.1.0h (Affected 1.1.0-1.1.0g). Fixed in OpenSSL 1.0.2o (Affected 1.0.2b-1.0.2n).
Issue summary: Processing some specially crafted ASN.1 object identifiers or
data containing them may be very slow.
Impact summary: Applications that use OBJ_obj2txt() directly, or use any of
the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message
size limit may experience notable to very long delays when processing those
messages, which may lead to a Denial of Service.
An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -
most of which have no size limit. OBJ_obj2txt() may be used to translate
an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL
type ASN1_OBJECT) to its canonical numeric text form, which are the
sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by
periods.
When one of the sub-identifiers in the OBJECT IDENTIFIER is very large
(these are sizes that are seen as absurdly large, taking up tens or hundreds
of KiBs), the translation to a decimal number in text may take a very long
time. The time complexity is O(n^2) with 'n' being the size of the
sub-identifiers in bytes (*).
With OpenSSL 3.0, support to fetch cryptographic algorithms using names /
identifiers in string form was introduced. This includes using OBJECT
IDENTIFIERs in canonical numeric text form as identifiers for fetching
algorithms.
Such OBJECT IDENTIFIERs may be received through the ASN.1 structure
AlgorithmIdentifier, which is commonly used in multiple protocols to specify
what cryptographic algorithm should be used to sign or verify, encrypt or
decrypt, or digest passed data.
Applications that call OBJ_obj2txt() directly with untrusted data are
affected, with any version of OpenSSL. If the use is for the mere purpose
of display, the severity is considered low.
In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,
CMS, CMP/CRMF or TS. It also impacts anything that processes X.509
certificates, including simple things like verifying its signature.
The impact on TLS is relatively low, because all versions of OpenSSL have a
100KiB limit on the peer's certificate chain. Additionally, this only
impacts clients, or servers that have explicitly enabled client
authentication.
In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,
such as X.509 certificates. This is assumed to not happen in such a way
that it would cause a Denial of Service, so these versions are considered
not affected by this issue in such a way that it would be cause for concern,
and the severity is therefore considered low.
CVE-2017-3737openssl 1.0.2kCVSS 5.9
Matched product: openssl 1.0.2k Confidence: High
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p).
If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q).
A timing based side channel exists in the OpenSSL RSA Decryption implementation
which could be sufficient to recover a plaintext across a network in a
Bleichenbacher style attack. To achieve a successful decryption an attacker
would have to be able to send a very large number of trial messages for
decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5,
RSA-OEAP and RSASVE.
For example, in a TLS connection, RSA is commonly used by a client to send an
encrypted pre-master secret to the server. An attacker that had observed a
genuine connection between a client and a server could use this flaw to send
trial messages to the server and record the time taken to process them. After a
sufficiently large number of messages the attacker could recover the pre-master
secret used for the original connection and thus be able to decrypt the
application data sent over that connection.
Improper escaping of output in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to map URLs to filesystem locations that are permitted to be served by the server but are not intentionally/directly reachable by any URL, resulting in code execution or source code disclosure.
Substitutions in server context that use a backreferences or variables as the first segment of the substitution are affected. Some unsafe RewiteRules will be broken by this change and the rewrite flag "UnsafePrefixStat" can be used to opt back in once ensuring the substitution is appropriately constrained.
A crafted request uri-path can cause mod_proxy to forward the request to an origin server choosen by the remote user. This issue affects Apache HTTP Server 2.4.48 and earlier.
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication phase may lead to authentication requirements being bypassed.
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime can read one byte past the end of a buffer when sending a malicious Content-Type response header.
In Apache httpd 2.2.0 to 2.4.29, when generating an HTTP Digest authentication challenge, the nonce sent to prevent reply attacks was not correctly generated using a pseudo-random seed. In a cluster of servers using a common Digest authentication configuration, HTTP requests could be replayed across servers by an attacker without detection.
ap_escape_quotes() may write beyond the end of a buffer when given malicious input. No included modules pass untrusted data to these functions, but third-party / external modules may. This issue affects Apache HTTP Server 2.4.48 and earlier.
A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser (r:parsebody() called from Lua scripts). The Apache httpd team is not aware of an exploit for the vulnerabilty though it might be possible to craft one. This issue affects Apache HTTP Server 2.4.51 and earlier.
Apache HTTP Server 2.4.52 and earlier fails to close inbound connection when errors are encountered discarding the request body, exposing the server to HTTP Request Smuggling
Out-of-bounds Write vulnerability in mod_sed of Apache HTTP Server allows an attacker to overwrite heap memory with possibly attacker provided data. This issue affects Apache HTTP Server 2.4 version 2.4.52 and prior versions.
Apache HTTP Server 2.4.53 and earlier may not send the X-Forwarded-* headers to the origin server based on client side Connection header hop-by-hop mechanism. This may be used to bypass IP based authentication on the origin server/application.
Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack.
Configurations are affected when mod_proxy is enabled along with some form of RewriteRule
or ProxyPassMatch in which a non-specific pattern matches
some portion of the user-supplied request-target (URL) data and is then
re-inserted into the proxied request-target using variable
substitution. For example, something like:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
Request splitting/smuggling could result in bypass of access controls in the proxy server, proxying unintended URLs to existing origin servers, and cache poisoning. Users are recommended to update to at least version 2.4.56 of Apache HTTP Server.
Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts in
directories permitted by the configuration but not directly reachable by any URL or source disclosure of scripts meant to only to be executed as CGI.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Some RewriteRules that capture and substitute unsafely will now fail unless rewrite flag "UnsafeAllow3F" is specified.
Vulnerability in core of Apache HTTP Server 2.4.59 and earlier are vulnerably to information disclosure, SSRF or local script execution via backend applications whose response headers are malicious or exploitable.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Heap-based Buffer Overflow vulnerability in mod_proxy_ajp of Apache HTTP Server.
If mod_proxy_ajp connects to a malicious AJP server this AJP server can send a malicious AJP message back to mod_proxy_ajp and cause it to write 4 attacker controlled bytes after the end of a heap based buffer.
This issue affects Apache HTTP Server: through 2.4.66.
Users are recommended to upgrade to version 2.4.67, which fixes the issue.
Use After Free vulnerability in Apache HTTP Server with mod_ldap in per-directory configuration
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.
Users are recommended to upgrade to version 2.4.68, which fixes the issue.
Buffer Underwrite vulnerability in Apache HTTP Server on crafted regular expressions in the configuration.
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.
Users are recommended to upgrade to version 2.4.68, which fixes the issue.
In Apache httpd before 2.2.34 and 2.4.x before 2.4.27, the value placeholder in [Proxy-]Authorization headers of type 'Digest' was not initialized or reset before or between successive key=value assignments by mod_auth_digest. Providing an initial key with no '=' assignment could reflect the stale value of uninitialized pool memory used by the prior request, leading to leakage of potentially confidential information, and a segfault in other cases resulting in denial of service.
If LimitXMLRequestBody is set to allow request bodies larger than 350MB (defaults to 1M) on 32 bit systems an integer overflow happens which later causes out of bounds writes. This issue affects Apache HTTP Server 2.4.52 and earlier.
Apache HTTP Server 2.4.53 and earlier may crash or disclose information due to a read beyond bounds in ap_strcmp_match() when provided with an extremely large input buffer. While no code distributed with the server can be coerced into such a call, third-party modules or lua scripts that use ap_strcmp_match() may hypothetically be affected.
A path handling issue in mod_dav_fs in Apache 2.4.67 and earlier allows a WebDAV content author to directly manipulate trusted DAV property databases, potentially causing child process crashes.
Users are recommended to upgrade to version 2.4.68, which fixes this issue.
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.54 and prior versions.
An escalation of privilege bug in various modules in Apache HTTP 2.4.66 and earlier allows local .htaccess authors to read files with the privileges of the httpd user.
Users are recommended to upgrade to version 2.4.67, which fixes this issue.
Apache HTTP Server 2.4.65 and earlier with Server Side Includes (SSI) enabled and mod_cgid (but not mod_cgi) passes the shell-escaped query string to #exec cmd="..." directives.
This issue affects Apache HTTP Server before 2.4.66.
Users are recommended to upgrade to version 2.4.66, which fixes the issue.
In Apache httpd 2.4.0 to 2.4.29, the expression specified in <FilesMatch> could match '$' to a newline character in a malicious filename, rather than matching only the end of the filename. This could be exploited in environments where uploads of some files are are externally blocked, but only by matching the trailing portion of the filename.
The zend_string_extend function in Zend/zend_string.h in PHP through 7.1.5 does not prevent changes to string objects that result in a negative length, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact by leveraging a script's use of .= with a long string.
The Keccak XKCP SHA-3 reference implementation before fdc6fef has an integer overflow and resultant buffer overflow that allows attackers to execute arbitrary code or eliminate expected cryptographic properties. This occurs in the sponge function interface.
A command inject vulnerability allows an attacker to perform command injection on Windows applications that indirectly depend on the CreateProcess function when the specific conditions are satisfied.
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the vulnerability enables network and same-site attackers to set a standard insecure cookie in the victim's browser which is treated as a `__Host-` or `__Secure-` cookie by PHP applications.
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress "quines" gzip files, resulting in an infinite loop.
In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.* before 8.3.8, due to a code logic error, filtering functions such as filter_var when validating URLs (FILTER_VALIDATE_URL) for certain types of URLs the function will result in invalid user information (username + password part of URLs) being treated as valid user information. This may lead to the downstream code accepting invalid URLs as valid and parsing them incorrectly.
OpenSSL is a software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end.
Issue summary: A specially crafted PKCS#7 or S/MIME signed message could
trigger a use-after-free during PKCS#7 signature verification.
Impact summary: A use-after-free may result in process crashes, heap
corruption, or potentially remote code execution.
When processing a PKCS#7 or S/MIME signed message, if the SignedData
digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may
incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent
use of the BIO by the calling application results in a use-after-free
condition.
In the common case this occurs when the application later calls
BIO_free() on the BIO originally passed to PKCS7_verify(). Depending
on allocator behavior and application-specific BIO usage patterns, this
may result in a crash or other memory corruption. In some application
contexts this may potentially be exploitable for remote code execution.
Applications that process PKCS#7 or S/MIME signed messages using OpenSSL
PKCS#7 APIs may be affected. Applications using the CMS APIs for this
processing are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: A signed integer overflow when sizing the destination
buffer for Unicode output in ASN1_mbstring_ncopy() can lead to a heap
buffer overflow.
Impact summary: A heap buffer overflow may lead to a crash or possibly
attacker controlled code execution or other undefined behaviour.
In ASN1_mbstring_copy() and ASN1_mbstring_ncopy() the destination
size for Unicode output is computed in a signed int: by left shift
of the input character count for BMPSTRING (UTF-16) and
UNIVERSALSTRING (UTF-32), and by summing per-character byte counts
for UTF8STRING. The calculation overflows when the input reaches
around 2^30 characters. In the worst case (UNIVERSALSTRING at 2^30
characters) the size wraps to zero, OPENSSL_malloc(1) is called, and
the subsequent character copy writes several gigabytes past the
one-byte allocation.
X.509 certificate processing routes through ASN1_STRING_set_by_NID(),
whose DIRSTRING_TYPE mask excludes UNIVERSALSTRING and whose per-NID
size limits cap the input length; no network protocol or
certificate-handling path in OpenSSL exercises the overflow.
Triggering the bug requires an application that calls
ASN1_mbstring_copy() or ASN1_mbstring_ncopy() directly, or registers
a custom string type via ASN1_STRING_TABLE_add(), with
attacker-controlled input on the order of half a gigabyte or more.
For these reasons this issue was assigned Low severity.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by
this issue, as the affected code is outside the OpenSSL FIPS module
boundary.
During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Fixed in OpenSSL 1.1.0i-dev (Affected 1.1.0-1.1.0h). Fixed in OpenSSL 1.0.2p-dev (Affected 1.0.2-1.0.2o).
Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).
CVE-2023-0215openssl 1.0.2kCVSS 7.5
Matched product: openssl 1.0.2k Confidence: High
The public API function BIO_new_NDEF is a helper function used for streaming
ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the
SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by
end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter
BIO onto the front of it to form a BIO chain, and then returns the new head of
the BIO chain to the caller. Under certain conditions, for example if a CMS
recipient public key is invalid, the new filter BIO is freed and the function
returns a NULL result indicating a failure. However, in this case, the BIO chain
is not properly cleaned up and the BIO passed by the caller still retains
internal pointers to the previously freed filter BIO. If the caller then goes on
to call BIO_pop() on the BIO then a use-after-free will occur. This will most
likely result in a crash.
This scenario occurs directly in the internal function B64_write_ASN1() which
may cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on
the BIO. This internal function is in turn called by the public API functions
PEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream,
SMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7.
Other public API functions that may be impacted by this include
i2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and
i2d_PKCS7_bio_stream.
The OpenSSL cms and smime command line applications are similarly affected.
A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints. Attackers may be able to exploit this
vulnerability by creating a malicious certificate chain that triggers
exponential use of computational resources, leading to a denial-of-service
(DoS) attack on affected systems.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer
dereference in the PKCS12_item_decrypt_d2i_ex() function.
Impact summary: A NULL pointer dereference can trigger a crash which leads to
Denial of Service for an application processing PKCS#12 files.
The PKCS12_item_decrypt_d2i_ex() function does not check whether the oct
parameter is NULL before dereferencing it. When called from
PKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter can
be NULL, causing a crash. The vulnerability is limited to Denial of Service
and cannot be escalated to achieve code execution or memory disclosure.
Exploiting this issue requires an attacker to provide a malformed PKCS#12 file
to an application that processes it. For that reason the issue was assessed as
Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Issue summary: When a delta CRL that contains a Delta CRL Indicator extension
is processed a NULL pointer dereference might happen if the required CRL
Number extension is missing.
Impact summary: A NULL pointer dereference can trigger a crash which
leads to a Denial of Service for an application.
When CRL processing and delta CRL processing is enabled during X.509
certificate verification, the delta CRL processing does not check
whether the CRL Number extension is NULL before dereferencing it.
When a malformed delta CRL file is being processed, this parameter
can be NULL, causing a NULL pointer dereference.
Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in
the verification context, the certificate being verified to contain a
freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and
an attacker to provide a malformed CRL to an application that processes it.
The vulnerability is limited to Denial of Service and cannot be escalated to
achieve code execution or memory disclosure. For that reason the issue was
assessed as Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: During processing of a crafted CMS EnvelopedData message
with KeyAgreeRecipientInfo a NULL pointer dereference can happen.
Impact summary: Applications that process attacker-controlled CMS data may
crash before authentication or cryptographic operations occur resulting in
Denial of Service.
When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is
processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier
is examined without checking for its presence. This results in a NULL
pointer dereference if the field is missing.
Applications and services that call CMS_decrypt() on untrusted input
(e.g., S/MIME processing or CMS-based protocols) are vulnerable.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: During processing of a crafted CMS EnvelopedData message
with KeyTransportRecipientInfo a NULL pointer dereference can happen.
Impact summary: Applications that process attacker-controlled CMS data may
crash before authentication or cryptographic operations occur resulting in
Denial of Service.
When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with
RSA-OAEP encryption is processed, the optional parameters field of
RSA-OAEP SourceFunc algorithm identifier is examined without checking
for its presence. This results in a NULL pointer dereference if the field
is missing.
Applications and services that call CMS_decrypt() on untrusted input
(e.g., S/MIME processing or CMS-based protocols) are vulnerable.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: Parsing a crafted DER-encoded ASN.1 structure with a primitive
element whose content exceeds 2 gigabytes in length may cause a heap buffer
over-read on 64-bit Unix and Unix-like platforms.
Impact summary: The heap buffer over-read may crash the application (Denial of
Service) or to load into the decoded ASN.1 object contents of memory beyond the
end of the input buffer. More typically such ASN.1 elements would instead be
truncated.
An integer truncation in OpenSSL's ASN.1 decoder causes the content length of
an ASN.1 primitive element to be mishandled when it exceeds 2 gigabytes. In the
worst case the truncated length is treated as a request to scan the binary
content for a terminating zero byte, possibly causing OpenSSL to read either
less than or beyond the end of the allocated buffer.
Applications that pass attacker-supplied data to d2i_X509(), d2i_PKCS7(), or
any other d2i_* decoding function are affected. OpenSSL's own command-line
tools are not vulnerable, as data read through the BIO layer is checked before
it reaches the affected code. The issue only affects 64-bit Unix and Unix-like
platforms; 32-bit platforms and 64-bit Windows are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by this issue,
as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap)
processes attacker-supplied CMS data, an attacker-chosen stream-mode KEK
cipher can trigger a heap out-of-bounds read in kek_unwrap_key().
Impact summary: A heap buffer over-read may trigger a crash which leads to
Denial of Service for an application if the input buffer ends at a memory
page boundary and the following page is unmapped. There is no information
disclosure as the over-read bytes are not revealed to the attacker.
The key unwrapping function performs a check-byte test as specified in the
RFC that reads 7 bytes from a heap allocation that is based on the wrapped
key length from the message. There is a minimum length check based on the
block length of the wrapping cipher. However the cipher is selected from
an OID carried in the attacker's PWRI keyEncryptionAlgorithm with no
requirement that the cipher be a block cipher. When an attacker selects
a stream-mode cipher the guard will be ineffective and the allocated buffer
containing the unwrapped key can be too small to fit the check-bytes
specified in the RFC and a buffer over-read can happen.
Applications calling CMS_decrypt() or CMS_decrypt_set1_password()
(equivalently openssl cms -decrypt -pwri_password ...) on untrusted CMS
data are vulnerable to this issue. No password knowledge is required: the
over-read happens during the unwrap attempt before any authentication
succeeds.
The over-read is limited to a few bytes and is not written to output, so
there is no information disclosure. Triggering a crash requires the
allocation to border unmapped memory, which is unlikely with the normal
allocator.
The FIPS modules are not affected by this issue.
ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
CVE-2023-0286openssl 1.0.2kCVSS 7.4
Matched product: openssl 1.0.2k Confidence: High
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but
the public structure definition for GENERAL_NAME incorrectly specified the type
of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by
the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an
ASN1_STRING.
When CRL checking is enabled (i.e. the application sets the
X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass
arbitrary pointers to a memcmp call, enabling them to read memory contents or
enact a denial of service. In most cases, the attack requires the attacker to
provide both the certificate chain and CRL, neither of which need to have a
valid signature. If the attacker only controls one of these inputs, the other
input must already contain an X.400 address as a CRL distribution point, which
is uncommon. As such, this vulnerability is most likely to only affect
applications which have implemented their own functionality for retrieving CRLs
over a network.
The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd).
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze).
There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL before 1.0.2m and 1.1.0 before 1.1.0g. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.
Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe. Fixed in OpenSSL 1.1.0h (Affected 1.1.0-1.1.0g). Fixed in OpenSSL 1.0.2o (Affected 1.0.2b-1.0.2n).
Issue summary: Processing some specially crafted ASN.1 object identifiers or
data containing them may be very slow.
Impact summary: Applications that use OBJ_obj2txt() directly, or use any of
the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message
size limit may experience notable to very long delays when processing those
messages, which may lead to a Denial of Service.
An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -
most of which have no size limit. OBJ_obj2txt() may be used to translate
an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL
type ASN1_OBJECT) to its canonical numeric text form, which are the
sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by
periods.
When one of the sub-identifiers in the OBJECT IDENTIFIER is very large
(these are sizes that are seen as absurdly large, taking up tens or hundreds
of KiBs), the translation to a decimal number in text may take a very long
time. The time complexity is O(n^2) with 'n' being the size of the
sub-identifiers in bytes (*).
With OpenSSL 3.0, support to fetch cryptographic algorithms using names /
identifiers in string form was introduced. This includes using OBJECT
IDENTIFIERs in canonical numeric text form as identifiers for fetching
algorithms.
Such OBJECT IDENTIFIERs may be received through the ASN.1 structure
AlgorithmIdentifier, which is commonly used in multiple protocols to specify
what cryptographic algorithm should be used to sign or verify, encrypt or
decrypt, or digest passed data.
Applications that call OBJ_obj2txt() directly with untrusted data are
affected, with any version of OpenSSL. If the use is for the mere purpose
of display, the severity is considered low.
In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,
CMS, CMP/CRMF or TS. It also impacts anything that processes X.509
certificates, including simple things like verifying its signature.
The impact on TLS is relatively low, because all versions of OpenSSL have a
100KiB limit on the peer's certificate chain. Additionally, this only
impacts clients, or servers that have explicitly enabled client
authentication.
In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,
such as X.509 certificates. This is assumed to not happen in such a way
that it would cause a Denial of Service, so these versions are considered
not affected by this issue in such a way that it would be cause for concern,
and the severity is therefore considered low.
CVE-2017-3737openssl 1.0.2kCVSS 5.9
Matched product: openssl 1.0.2k Confidence: High
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL version 1.0.2-1.0.2m and 1.1.0-1.1.0g are affected. Fixed in OpenSSL 1.0.2n. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository.
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side channel attack. An attacker could use variations in the signing algorithm to recover the private key. Fixed in OpenSSL 1.1.1a (Affected 1.1.1). Fixed in OpenSSL 1.1.0j (Affected 1.1.0-1.1.0i). Fixed in OpenSSL 1.0.2q (Affected 1.0.2-1.0.2p).
If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q).
A timing based side channel exists in the OpenSSL RSA Decryption implementation
which could be sufficient to recover a plaintext across a network in a
Bleichenbacher style attack. To achieve a successful decryption an attacker
would have to be able to send a very large number of trial messages for
decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5,
RSA-OEAP and RSASVE.
For example, in a TLS connection, RSA is commonly used by a client to send an
encrypted pre-master secret to the server. An attacker that had observed a
genuine connection between a client and a server could use this flaw to send
trial messages to the server and record the time taken to process them. After a
sufficiently large number of messages the attacker could recover the pre-master
secret used for the original connection and thus be able to decrypt the
application data sent over that connection.
Bootstrap is a free and open-source CSS framework directed at responsive, mobile-first front-end web development. It contains CSS and JavaScript-based design templates for typography, forms, buttons, navigation, and other interface components.
CCentOSVersion not visibleOperating SystemsVersion not visible
ConfidenceMedium
CentOS is a Linux distribution that provides a free, community-supported computing platform functionally compatible with its upstream source, Red Hat Enterprise Linux (RHEL).
jQuery is a JavaScript library which is a free, open-source software designed to simplify HTML DOM tree traversal and manipulation, as well as event handling, CSS animation, and Ajax.