According to secunia: A buffer overflow vulnerability exists in the htdigest utility included with Apache. The vulnerability is due to improper bounds checking when copying user-supplied realm data into local buffers. By supplying an overly long realm value to the command line options of htdigest, it is possible to trigger an overflow condition. This may cause memory to be corrupted with attacker-specified values. This issue could be exploited by a remote attacker; potentially resulting in the execution of arbitrary system commands within the context of the web server process. Solution: USN-120-1 Reproducible: Always Steps to Reproduce:
Apache please advise
"This issue could be exploited by a remote attacker; potentially resulting in the execution of arbitrary system commands within the context of the web server process." That is extremely deceptive. The issue was only in the command line program -- not something that is norammly exposed to the web -- you would have to write your own code to expose it. Calling it a remote vulnerability isn't very truthful, IMHO. Anyways, the issue is fixed in 2.0.54.
Thx for the info Paul.
apache-2.0.54-r2 is in the tree to satisfy this this bug. If this comes to a GLSA could it please be mentioned that -r2 and -r3 are old-style (stable) and new style (testing, aka 'apache refreshed' ebuilds), respectively - we have a feeling this bump may confuse users. Anyway .. Tested and marked stable on x86. Arches, please test and mark apache-2.0.54-r2 stable. Thanks !
-r2 stable on ppc64
2.0.54-r2 blocks mod_php Msg: emerge -Duav world [blocks B ] >=net-www/apache-2.0.52-r3 (is blocking dev-php/mod_php-4.3.11)
it also blocks the latest x86 subversion
Oops, it's -r2 is now stable on ppc. Didn't reloaded the bug. But mod_php does not have dependency problems on ppc.
Note that /usr/sbin/apache2splitlogfile no longer gets installed with executable permissions, which appeared to cause me some usability problems until I adjusted it by hand.
Besides the apache2splitlogfile issue there's also problems with a mod_php blocker. Please hold off stabling apache until I have new fixed ebuilds in the tree.
Back to ebuild status to get this sorted out.
Stable on hppa.
Unstable again.
-r4 and -r5 are in the tree, same game as above (-r4 is the old-style, to be marked stable, -r5 is the new-style 'apache refresh' ebuild, to be left alone !). Apologies for all the mess, I'll be handing out free-beer-if-your-ever-in-the-uk IOUs in #-dev shortly. :) Thoroughly tested, and marked stable on x86. Arches, please test and mark apache-2.0.54-r4 stable (remember to kick beu on your way out). Thanks !
Thx Elfyn. Btw did you see beu anywhere? ;-)
Stable on alpha.
Stable on ia64.
Stable on ppc (again).
-r4 stable on ppc64
GMsoft has marked it already stable.
Not sure this should be considered a bug. We had several like this one before that we discarded, including in htpasswd. I don't see an obvious path for a remote attacker (it's not like if htdigest was commonly called in web applications) and untrusted input should always be filtered before being used in a command line... So I would discard this one as INVALID, even if it's a bug needing a fix.
Upstream agrees -> Closing as INVALID. Sorry for the spam:-(
