FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The last vuln.xml file processed by FreshPorts is:

Revision:  556810
Date:      2020-12-02
Time:      10:03:15Z
Committer: philip

List all Vulnerabilities, by package

List all Vulnerabilities, by date

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
3f98ccb3-6b8a-11e9-9b5c-a4badb296695Dovecot -- Multiple vulnerabilities

Aki Tuomi reports:

Submission-login crashes with signal 11 due to null pointer access when authentication is aborted by disconnecting. This can lead to denial-of-service attack by persistent attacker(s).

Aki Tuomi reports:

Submission-login crashes when authentication is started over TLS secured channel and invalid authentication message is sent. This can lead to denial-of-service attack by persistent attacker(s).

Discovery 2019-03-11
Entry 2019-04-30
ge 2.3.0 lt 2.3.6
a64aa22f-61ec-11e9-85b9-a4badb296695dovecot -- json encoder crash

Aki Tuomi reports:

* CVE-2019-10691: Trying to login with 8bit username containing invalid UTF8 input causes auth process to crash if auth policy is enabled. This could be used rather easily to cause a DoS. Similar crash also happens during mail delivery when using invalid UTF8 in From or Subject header when OX push notification driver is used.

Discovery 2019-04-09
Entry 2019-04-18
Modified 2019-05-26
ge 2.3.0 lt

ge 2.3.0 lt
abaaecda-ea16-43e2-bad0-d34a9ac576b1Dovecot -- improper input validation

Aki Tuomi reports:

Vulnerability Details: IMAP and ManageSieve protocol parsers do not properly handle NUL byte when scanning data in quoted strings, leading to out of bounds heap memory writes. Risk: This vulnerability allows for out-of-bounds writes to objects stored on the heap up to 8096 bytes in pre-login phase, and 65536 bytes post-login phase, allowing sufficiently skilled attacker to perform complicated attacks that can lead to leaking private information or remote code execution. Abuse of this bug is very difficult to observe, as it does not necessarily cause a crash. Attempts to abuse this bug are not directly evident from logs.

Discovery 2019-04-13
Entry 2019-08-28

7862213c-5152-11e9-8b26-a4badb296695dovecot -- Buffer overflow reading extension header

Aki Tuomi reports:

Vulnerability Details: When reading FTS or POP3-UIDL header from dovecot index, the input buffer size is not bound, and data is copied to target structure causing stack overflow. Risk: This can be used for local root privilege escalation or executing arbitrary code in dovecot process context. This requires ability to directly modify dovecot indexes. Steps to reproduce: Produce dovecot.index.log entry that creates an FTS header which has more than 12 bytes of data. Trigger dovecot indexer-worker or run doveadm index. Dovecot will crash. Mitigations: Since 2.3.0 dovecot has been compiled with stack smash protection, ASLR, read-only GOT tables and other techniques that make exploiting this bug much harder.

Discovery 2019-02-05
Entry 2019-03-28
1340fcc1-2953-11e9-bc44-a4badb296695mail/dovecot -- Suitable client certificate can be used to login as other user

Aki Tuomi (Open-Xchange Oy) reports:

Normally Dovecot is configured to authenticate imap/pop3/managesieve/submission clients using regular username/password combination. Some installations have also required clients to present a trusted SSL certificate on top of that. It's also possible to configure Dovecot to take the username from the certificate instead of from the user provided authentication. It's also possible to avoid having a password at all, only trusting the SSL certificate. If the provided trusted SSL certificate is missing the username field, Dovecot should be failing the authentication. However, the earlier versions will take the username from the user provided authentication fields (e.g. LOGIN command). If there is no additional password verification, this allows the attacker to login as anyone else in the system. This affects only installations using: auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes Attacker must also have access to a valid trusted certificate without the ssl_cert_username_field in it. The default is commonName, which almost certainly exists in all certificates. This could happen for example if ssl_cert_username_field is a field that normally doesn't exist, and attacker has access to a web server's certificate (and key), which is signed with the same CA. Attack can be migitated by having the certificates with proper Extended Key Usage, such as 'TLS Web Server' and 'TLS Web Server Client'. Also, ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This does not apply to Dovecot Submission service.

Discovery 2019-01-16
Entry 2019-02-05