You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Jacobs <ej...@bluehost.com> on 2012/10/31 05:46:47 UTC
[patch] Fix cross-user symlink race condition vulnerability
There is a race condition vulnerability in httpd 2.2.23 (also present in
previous releases) that allows a malicious user to serve arbitrary files
from nearly anywhere on a server that isn't protected by strict os level
permissions. In a shared hosting environment, this is a big vulnerability.
If you would like more information on the exploit itself, please let me
know. I have a proof of concept that is able to hit the exploit with
100% success.
This is my first patch submitted to Apache, so I'm sorry if I've missed
something. I'm aware that this doesn't meet some of the code standards
that are in place (e.g, it doesn't work at all on Windows), but I wanted
to put it out there anyway.
The patch that fixes the vulnerability is attached. Thank you in advance
for the feedback.
--
Eric Jacobs
Junior Systems Administrator
Bluehost.com
Re: [patch] Fix cross-user symlink race condition vulnerability
Posted by Christophe JAILLET <ch...@wanadoo.fr>.
Le 31/10/2012 05:46, Eric Jacobs a écrit :
> There is a race condition vulnerability in httpd 2.2.23 (also present
> in previous releases) that allows a malicious user to serve arbitrary
> files from nearly anywhere on a server that isn't protected by strict
> os level permissions. In a shared hosting environment, this is a big
> vulnerability.
>
> If you would like more information on the exploit itself, please let
> me know. I have a proof of concept that is able to hit the exploit
> with 100% success.
>
> This is my first patch submitted to Apache, so I'm sorry if I've
> missed something. I'm aware that this doesn't meet some of the code
> standards that are in place (e.g, it doesn't work at all on Windows),
> but I wanted to put it out there anyway.
>
> The patch that fixes the vulnerability is attached. Thank you in
> advance for the feedback.
>
Hi,
could you please open a bug report on bugzilla
(https://issues.apache.org/bugzilla/) so that your message and proposed
patch does not get lost in this mailing list.
Thanks in advance.
Best regards,
Christophe JAILLET
Re: [patch] Fix cross-user symlink race condition vulnerability
Posted by Eric Covener <co...@gmail.com>.
On Wed, Oct 31, 2012 at 3:36 PM, Eric Jacobs <ej...@bluehost.com> wrote:
> On 10/31/2012 06:00 AM, Eric Covener wrote:
>>
>> In general that is the proper form -- but this particular issue is
>> documented as a limitation:
>>
>> "Omitting this option should not be considered a security restriction,
>> since symlink testing is subject to race conditions that make it
>> circumventable."
>
>
> Some users (like Bluehost) require the functionality of symlinks without the
> possibility of server side vulnerabilities. Having the vulnerability
> documented doesn't keep servers safe.
My point was that discussion of this particular issue does not need to
be segregated to the private security list.
Re: [patch] Fix cross-user symlink race condition vulnerability
Posted by Lazy <la...@gmail.com>.
2012/10/31 Eric Jacobs <ej...@bluehost.com>:
> On 10/31/2012 06:00 AM, Eric Covener wrote:
>>
>> In general that is the proper form -- but this particular issue is
>> documented as a limitation:
>>
>> "Omitting this option should not be considered a security restriction,
>> since symlink testing is subject to race conditions that make it
>> circumventable."
>
>
> Some users (like Bluehost) require the functionality of symlinks without the
> possibility of server side vulnerabilities. Having the vulnerability
> documented doesn't keep servers safe. The patch I submitted allows httpd to
> use symlinks in a protected fashion that doesn't allow for users to serve
> arbitrary files.
>
> I'll go ahead and submit a more detailed email to the security. More
> feedback from the devs is appreciated.
on some systems, at least on Linux You can use a grsecurity kernel
patch feature which prevents those races
and is cheeper performance wise
+config GRKERNSEC_SYMLINKOWN
+ bool "Kernel-enforced SymlinksIfOwnerMatch"
+ default y if GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_SERVER
+ help
+ Apache's SymlinksIfOwnerMatch option has an inherent race condition
+ that prevents it from being used as a security feature. As Apache
+ verifies the symlink by performing a stat() against the target of
+ the symlink before it is followed, an attacker can setup a symlink
+ to point to a same-owned file, then replace the symlink with one
+ that targets another user's file just after Apache "validates" the
+ symlink -- a classic TOCTOU race. If you say Y here, a complete,
+ race-free replacement for Apache's "SymlinksIfOwnerMatch" option
+ will be in place for the group you specify. If the sysctl option
+ is enabled, a sysctl option with name "enforce_symlinksifowner" is
+ created.
there probably is something similar on *BSD's, or if there isn't it
won't be hard to make
Your patch checks for a race conditions every time, even if Symlinks
weren't allowed. It also references some
configuration dependent directory like /usr/local/apache/htdocs.
--
Michal Grzedzicki
Re: [patch] Fix cross-user symlink race condition vulnerability
Posted by Eric Jacobs <ej...@bluehost.com>.
On 10/31/2012 06:00 AM, Eric Covener wrote:
> In general that is the proper form -- but this particular issue is
> documented as a limitation:
>
> "Omitting this option should not be considered a security restriction,
> since symlink testing is subject to race conditions that make it
> circumventable."
Some users (like Bluehost) require the functionality of symlinks without
the possibility of server side vulnerabilities. Having the vulnerability
documented doesn't keep servers safe. The patch I submitted allows httpd
to use symlinks in a protected fashion that doesn't allow for users to
serve arbitrary files.
I'll go ahead and submit a more detailed email to the security. More
feedback from the devs is appreciated.
--
Eric Jacobs
Junior Systems Administrator
Bluehost.com
Re: [patch] Fix cross-user symlink race condition vulnerability
Posted by Eric Covener <co...@gmail.com>.
On Wed, Oct 31, 2012 at 7:31 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 31 Oct 2012, at 6:46 AM, Eric Jacobs <ej...@bluehost.com> wrote:
>
>> There is a race condition vulnerability in httpd 2.2.23 (also present in previous releases) that allows a malicious user to serve arbitrary files from nearly anywhere on a server that isn't protected by strict os level permissions. In a shared hosting environment, this is a big vulnerability.
>>
>> If you would like more information on the exploit itself, please let me know. I have a proof of concept that is able to hit the exploit with 100% success.
>>
>> This is my first patch submitted to Apache, so I'm sorry if I've missed something. I'm aware that this doesn't meet some of the code standards that are in place (e.g, it doesn't work at all on Windows), but I wanted to put it out there anyway.
>>
>> The patch that fixes the vulnerability is attached. Thank you in advance for the feedback.
>
> As this is reported as a security issue, would it be possible instead to email the details to security@httpd.apache.org, and we can take a look?
>
In general that is the proper form -- but this particular issue is
documented as a limitation:
"Omitting this option should not be considered a security restriction,
since symlink testing is subject to race conditions that make it
circumventable."
Re: [patch] Fix cross-user symlink race condition vulnerability
Posted by Graham Leggett <mi...@sharp.fm>.
On 31 Oct 2012, at 6:46 AM, Eric Jacobs <ej...@bluehost.com> wrote:
> There is a race condition vulnerability in httpd 2.2.23 (also present in previous releases) that allows a malicious user to serve arbitrary files from nearly anywhere on a server that isn't protected by strict os level permissions. In a shared hosting environment, this is a big vulnerability.
>
> If you would like more information on the exploit itself, please let me know. I have a proof of concept that is able to hit the exploit with 100% success.
>
> This is my first patch submitted to Apache, so I'm sorry if I've missed something. I'm aware that this doesn't meet some of the code standards that are in place (e.g, it doesn't work at all on Windows), but I wanted to put it out there anyway.
>
> The patch that fixes the vulnerability is attached. Thank you in advance for the feedback.
As this is reported as a security issue, would it be possible instead to email the details to security@httpd.apache.org, and we can take a look?
Regards,
Graham
--