From the distros ML.

#### Description

Stack buffer overflow in libspf2 when processing certain SPF macros can 
lead to Denial of service and potentially code execution via malicious 
crafted SPF explanation messages. CVE-2021-20314 has been assigned to 
this issue.

#### Attack type

Remote

#### Impact

(x) Code Execution (x) Denial of Service

#### Attack vector(s):

Attackers need to cause a mail server to process a malicious SPF record, 
ie. via sending an email from an attacker-controlled domain. Thus, any 
mail server accepting mails and processing them via libspf2 is vulnerable.

#### CVE

Red Hat assigned CVE-2021-20314 for this already.

#### Patch

The issue has been fixed in github commit c37b7c1 without revealing the 
security impact of this issue:

https://github.com/shevek/libspf2/commit/c37b7c13c30e225183899364b9f2efdfa85552ef

An updated version of libspf2 (1.2.11) which also fixes other security 
related issues is available from github 
(https://github.com/shevek/libspf2). The libspf2 website 
(https://www.libspf2.org/download.html) and latest release there is NOT 
UPDATED YET.

#### Discoverer(s)/Credits

Philipp Jeitner and Haya Shulman, Fraunhofer SIT

philipp.jeitner@sit.fraunhofer.de
haya.shulman@sit.fraunhofer.de

#### Reference(s)

  - libspf2: https://www.libspf2.org/, https://github.com/shevek/libspf2
  - patch: 
https://github.com/shevek/libspf2/commit/c37b7c13c30e225183899364b9f2efdfa85552ef
  - Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS 
(https://www.usenix.org/conference/usenixsecurity21/presentation/jeitner 
, Available from August 11 2021)

#### Disclosure timeline

Details on the issue will be published on August 11, 2021 in our 
scientific paper "Injection Attacks Reloaded: Tunnelling Malicious 
Payloads over DNS" at USENIX Security 2021.

I'm aware of the policy of the 'distros' mailing list that "in case a 
fix for an issue is already in a publicly accessible source code 
repository, we generally consider the issue public (and thus you should 
post to oss-security right away".

However, the developer of libspf2 told me that he was unsuccessful in 
establishing direct contact with distributors to publish an updated 
version of libspf2 via distribution channels and thus, i think it is a 
good idea to not publish the details of this fix right away so updates 
can be shipped via distribution channels first. In case you do not agree 
with this assessment, I'm do not have any objections to publish the 
information in this email right now via 'oss-security'.

#### Details and information to reproduce the vulnerability

To reproduce, set the SPF record of a domain you control like listed below:

     example.com. 300    IN      TXT     "v=spf1 exp=exp.example.com"
     exp=exp.example.com.   300     IN      TXT 
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" 
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Then trigger SPF processing in libspf2, ie. via the command line 
`spfquery` tool.

     # spfquery --sender someone@example.com -ip 1.2.3.4
     *** stack smashing detected ***: terminated
     Aborted (core dumped)

The record causes a 4-byte stack buffer overflow of local variable `buf` 
in `SPF_record_compile_macro`, which is responsible for parsing the 
potential macros included in the SPF explanation message. The overflow 
is caused by an incorrect buffer length adjustment in the 
`SPF_INIT_STRING_LITERAL` macro  which  places  a  4-byte  header of 
type `SPF_data_str` into  the  buffer inside `buf` without  decreasing 
the  available size `ds_avail` by 4. Exploiting this vulnerability 
therefore allows  the  attacker to  override  up to  4  bytes  on  the 
stack of `SPF_record_compile_macro` directly after `buf`.