Is this for CVE-2021-20314
No; unfortunately, the vulnerabilities we've notified you about are two entirely
new buffer overflows discovered in libSPF2. They have CVE numbers assigned
(CVE-2021-33912 and CVE-2021-33913), but they are not yet publicly disclosed; they
have only been reserved.
Why did this notification come to my email address?
We discovered this vulnerability in servers hosted on over 7000 IP addresses;
as our research team is relatively small, we took a best-efforts automated approach
in selecting emails that would most likely be owned by email server administrators.
If you aren't the administrator of the email servers used for your email address,
please forward this on to them so that they can address the issue.
What exactly is the problem?
The software that runs on your email server uses libSPF2, a library that
provides the ability to check Sender Policy Framework (SPF) records. SPF records
are used to ensure that incoming emails do not have spoofed email addresses,
and it is good that your server is checking for these records. These records are
automatically queried for from the Domain Name System (DNS) whenever an email
is received by a server.
Earlier this year, our security lab discovered two buffer overflows present
in the libSPF2 source code. Both of these buffer overflows can be triggered when
a particular SPF record is assigned for a domain; as such, an attacker could
automatically trigger either of them simply by sending an email from a hostname
they own. We've released fixes to this issue and are measuring a wide variety of
email servers to notify administrators if they're affected; unfortunately, your
servers have been found to be using this vulnerable version of libSPF2.
How dangerous are the vulnerabilities?
Both buffer overflows discovered in libSPF2 can be triggered remotely--that
is, an attacker could publish a malicious SPF record on a domain they own (such
as `example.com`) and then send an email to your server from an email address
in that domain (such as `user@example.com`). Your email server would automatically
retrieve the SPF record, which would then lead to memory corruption on the server.
If the right SPF record were crafted, this could lead to a Denial of Service attack
(by crashing your email server) or even facilitate a Remote Code Execution attack
(where the attacker can gain remote access to read/write files and execute commands
on the email server).
No instances of these attacks have been found in the wild yet, but if such an
attack were crafted the impact would be severe--it could lead to the compromise of
email and user data, and it could additionally allow the attacker to send emails that
appear to come from your email address.
In order to provide you time to fix the vulnerability, we have refrained from
releasing any details on the vulnerability publicly. We ask that you keep information
on the libSPF2 vulnerabilities private until we publicly disclose details and CVE
numbers (see "When will this vulnerability be disclosed?" below).
How did you discover that my email is affected?
In order to help mitigate the impact of these vulnerabilities, we
performed measurements on email servers associated with websites on the
Alexa top 1 million list, as well as on a smaller list of hostnames
collected by measuring 2 weeks of email traffic at a medium-sized university.
The hostname to your email server ended up being in one of these two lists.
The actual measurement we performed was very minimal in nature--our
servers established an SMTP connection with your email server and initiated the
process of sending an email. Before the process was complete, our email would
disconnect (so as to avoid any emails actually being sent), and our DNS servers
would be queried by your server for SPF records. The vulnerabilities affecting
libSPF2 cause the DNS queries to be unique to other implementations, so if our
servers logged that particular pattern of DNS query then we could conclusively
determine that your server runs the vulnerable version of libSPF2. Unfortunately,
this is the case for your servers.
The tests we performed were completely benign. They were set up in
such a way that no memory was corrupted on your server, and they did not involved
any unauthorized access of services or information.
How do I fix the vulnerability on my system?
If you have administrative access to your email server, there are
two ways you can patch this vulnerability:
-
Changing SPF Implementation
If you use email software like Exim or Postfix, you can configure
it to use a safer implementation of SPF. The `Mail::SPF` Perl library and
`pyspf` python library are both well-used as extensions to Exim, Postfix,
and many other email server implementations, and there are plenty of tutorials
online on how to configure these.
-
Patching libSPF2
The current source code of libSPF2 has patches for all of the discovered
vulnerabilities. The 1.2.11 release, which contains these fixes, can be found
here.
Some package managers (such as Debian) have kept the old 1.2.10 version number
while applying the fixes as a patch. If you use a package manager for libSPF2, check
to ensure that it has been patched sufficiently; if it hasn't, you may need to apply
a patch manually to the library.
When will this vulnerability be publicly disclosed?
To give ample time for fixes, we will hold off from publishing any public
disclosure on the libSPF2 vulnerabilities until at least 60 days from now
(mid-January). However, we highly recommend you fix the configuration for
your server as soon as possible.
What if I don't want to receive any more emails about this?
If you received this message in error and/or would rather not receive any further
communications relating to this experiment, simply notify us at imaal-abuse@byu.edu.
If you have any additional questions or comments, you can contact us at the following email:
libspf2-vuln-info@byu.edu
