kag

Joined 15 years ago

Karma
58
Submissions
7
Member since
Jul 23
[ my public key: https://keybase.io/kag; my proof: https://keybase.io/kag/sigs/pSHhtMbBiy3nu3u8EqUXlhgGBTdwsLmZjTh9sbR6pXU ]
View on Hacker News

Recent submissions

Comment · 12 years ago
Of course bash doesn't know and shouldn't know about the SMTP RFCs. Yes, bash shouldn't execute code in variables. I was talking about input validation in qmail itself, not bash.

Even though bash shouldn't have executed the code, better input validation and RFC conformance in qmail could have prevented exploitation of bash. You know, defense-in-depth.

Comment · 12 years ago
Yeah, it does. I meant Debian, but it looks like Debian changed too. My bad. My point was that changing /bin/sh from the distro-chosen one to something else could cause problems.
Comment · 12 years ago
>> 2. uninstall Bash and use a barebones POSIX-like shell without extra features.

It's not that simple. True, djb doesn't say you need bash. But qmail uses /bin/sh (not configurable without recompiling). Try changing /bin/sh to, say, ksh on Ubuntu and watch as nothing else on the system works. The distributions make use of shell-specific features.

Comment · 12 years ago
Yes, this is not exploitable without vulnerable bash.

But to paraphrase from the thread:

However, qmail is not parsing mail from:<> and rcpt to:<> in accordance with RFC821/RFC2821. Almost anything is allowed between the <>. There is no reason that qmail should allow the string "() { :; }; nc -e /bin/bash localhost 7777" to ever pass through mail from:<> or rcpt to:<>, and thus into the environment, in the first place.

While the manpage does say what you pasted above, there's a difference between "may contain special characters" and "may contain anything the user puts in this part of the SMTP dialog".

Comment · 12 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton