Re: Bash CVE-2014-6271 and CGI / HTTPD
On Wed, 2014-09-24 at 22:15 +0200, Rainer Jung wrote:
One could try to sanitize env var contents in ap_create_environment()
though. Currently we do sanitize variable names there. But there's no
generally good pattern for the value sanitizing.
This is a revisiting of the classic perl/cgi untainting problem.
Perl's solution is to require anything from an untrusted source
to match a whitelist-style pattern before the system can be
exposed to it.
mod_taint would enable us to sanitise this, while offering
sysops flexibility to vary the sanitising rules.
The exploit is said to be any env var value looking like
() { something }; problematicPart
That's a pattern that can be regexp-matched. The regexp
could be hardwired in under the name CVE-2014-6271
for sysops who want an easy life. This solution
also places in sysops hands the decision whether to
de-fang the attack string or just return 400.
The problem might also apply to SSI and other interfaces that can set
environment variables, like maybe FCGI and SCGI (if they later trigger
bash calls).
So make it a system-wide default, and let the sysop turn it off
if they have a use for headers legitimately matching that pattern!
--
Nick Kew
Re: Bash CVE-2014-6271 and CGI / HTTPD
On Thu, Sep 25, 2014 at 10:53 AM, Nick Kew n...@apache.org wrote:
The exploit is said to be any env var value looking like
() { something }; problematicPart
That's a pattern that can be regexp-matched. The regexp
could be hardwired in under the name CVE-2014-6271
for sysops who want an easy life.
The latest news on this (CVE-2014-7169) suggest that bash's function
parser has more than this single issue, so the problematic pattern is
probably something as simple as:
( ) { problematicPart
Or as a PCRE :
^\s*\(\s*\)\s*\{.*
Regards,
Yann.
Re: Bash CVE-2014-6271 and CGI / HTTPD
I agree, but one-off, specific-case hacks like that are
usually more trouble then they are worth, imo at least.
What if we find another attack vector? Then we add another
special case, etc...
IMO, this is outside of httpd's realm to deal with...
Just my 2c
On Sep 24, 2014, at 4:21 PM, Rainer Jung rainer.j...@kippdata.de wrote:
Am 24.09.2014 um 22:15 schrieb Rainer Jung:
Am 24.09.2014 um 20:20 schrieb Eric Covener:
On Wed, Sep 24, 2014 at 1:48 PM, Paul Querna p...@querna.org
mailto:p...@querna.org wrote:
Thoughts? Is it reasonable to do something in mod_cgi{d} to improve
the situation?
I don't think so, even if we tried to figure out the interpreter, it
could run _anything_ else that is interpreted by bash.
But an announcement might be helpful to users.
One could try to sanitize env var contents in ap_create_environment()
though. Currently we do sanitize variable names there. But there's no
generally good pattern for the value sanitizing.
There's just a known one for this specific vulnerability, which might
break CGIs expecting content which is only problematic for broken bash.
So the sanitizing would be a workaround patch, which would only be
useful for people who can not quickly update their bash but can update
their web server. Not very likely but also not unthinkable of.
The exploit is said to be any env var value looking like
() { something }; problematicPart
So for instance optionally removing any semicolon from values would
help, but also likely break common values. I don't know, whether
removing () would suffice, or if an exploit could also contain
whitespace or even other chars between ( and ). Otherwise optionally
removing () would help.
The common recipes only work with a leading () in the variable value. So
removing () from the variable value if it starts with these two chars would
stop the problem.
The problem might also apply to SSI and other interfaces that can set
environment variables, like maybe FCGI and SCGI (if they later trigger
bash calls).
Regards,
Rainer
Re: What's need for http/2.0?
httpd side: serf to me is the wrong question. http/2.0 in the simplest implementation is just another protocol to httpd. We have the constructs to handle it, kinda. Improvements to async support in various bits will help. However our constructs about requests and connections (and their pools) are still grounded in the http1 mindset. http2 should challenge us to do real multiplexing of requests. I don't believe our existing hierarchy of pools deals well with the complexities of lifetime management of data in this multiplexed world, especially when you multiply that multiplexed nature of an http2 proxy (or reverse proxy) with its own outbound connections and requests. Additionally there are 'new' things that we don't deal with today, like: * Server Push * Stream Prioritization * Flow Control integration into proxy use cases Things like flow control and stream priorities interact poorly with the output current filter API and model -- calling the next function with a brigade, even if it wants you to try again, every caller has to deal with these complexities of back pressure -- I'd love to have more open discussion about ideas here. http2 will be around for another 20+ years, I'd challenge us to think about it as the default case, and http1 as a fallback case that we still support well, but the architecture and APIs are optimized for the future case. On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com wrote: APR: Considering that before we know it, http/2.0 will be here, and ignoring httpd for the time being, what features/additions do we see as being needed to support http/2.0 from an APR library level? How do we compare w/ libuv, for example? How event-aware should APR be, ala libevent? HTTPD: From the httpd point of view, what does serf provide for us to help us get to http/2.0? Should we make it a requirement? Are there things we need that, instead of making them part of httpd, should really be in APR instead? What other external libs should we be leveraging?
Re: What's need for http/2.0?
On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com wrote: APR: Considering that before we know it, http/2.0 will be here, and ignoring httpd for the time being, what features/additions do we see as being needed to support http/2.0 from an APR library level? How do we compare w/ libuv, for example? How event-aware should APR be, ala libevent? On APR: I mean. It's a platform layer over OS syscalls. it works. But... Having has a hand in early libuv development: libuv is fundamentally different -- everything is event based, anything that isn't able to be 'natively evented' into the OS event loop is dispatched to a thread pool. __This is nice because it gives you a constant abstraction to IO operations, not just the OS syscalls.__ APR lacks this POV. This has trade offs. Most commonly, File IO, as you need to do a blocking IO operation in another thread, which means you add a context switch or three to do IO. However with the changes to framing in http2, the days of just sendfile()'ing a file and blocking a thread are basically over, so maybe its not a huge deal in the end. As libuv was designed to be embedded in garbage collected languages, libuv also does not adopt pools. From my experience pools also tend to be harder to keep fine grained in most evented models, but this doesn't mean they couldn't be layered on top with care. My POV: I'd just use libuv, and port any APR-Util code to a library on top of libuv if it is needed. I'd probably keep pools for module level code using requests, but I'm unsure about connection pools honestly.
Re: What's need for http/2.0?
On Thu, 25 Sep 2014 05:26:38 -0700 Paul Querna p...@querna.org wrote: On Tue, Sep 23, 2014 at 12:45 PM, Jim Jagielski j...@jagunet.com wrote: APR: Considering that before we know it, http/2.0 will be here, and ignoring httpd for the time being, what features/additions do we see as being needed to support http/2.0 from an APR library level? How do we compare w/ libuv, for example? How event-aware should APR be, ala libevent? On APR: I mean. It's a platform layer over OS syscalls. it works. But... Having has a hand in early libuv development: libuv is fundamentally different -- everything is event based, anything that isn't able to be 'natively evented' into the OS event loop is dispatched to a thread pool. __This is nice because it gives you a constant abstraction to IO operations, not just the OS syscalls.__ APR lacks this POV. This has trade offs. Most commonly, File IO, as you need to do a blocking IO operation in another thread, which means you add a context switch or three to do IO. However with the changes to framing in http2, the days of just sendfile()'ing a file and blocking a thread are basically over, so maybe its not a huge deal in the end. As libuv was designed to be embedded in garbage collected languages, libuv also does not adopt pools. From my experience pools also tend to be harder to keep fine grained in most evented models, but this doesn't mean they couldn't be layered on top with care. My POV: I'd just use libuv, and port any APR-Util code to a library on top of libuv if it is needed. I'd probably keep pools for module level code using requests, but I'm unsure about connection pools honestly. I can give you a data point on memory management from the experience with event driven/async programming in the Samba project. There we use talloc, a hierarchical memory allocator, and we find it a great match for event driven/asynchronous models as it allows automatic cleanup of memory and other resources (like file handles) via destructors, yet each memory context can be really fine grained and tied well to the memory structures being used. I find pools extremely handy, but adding a hierarchical layer on them could make them better suited for event driven/asynchronous request mechanisms. my 2c, HTH. Simo. -- Simo Sorce * Red Hat, Inc * New York
Re: What's need for http/2.0?
On 25 Sep 2014, at 2:13 PM, Paul Querna p...@querna.org wrote: http/2.0 in the simplest implementation is just another protocol to httpd. We have the constructs to handle it, kinda. Improvements to async support in various bits will help. However our constructs about requests and connections (and their pools) are still grounded in the http1 mindset. http2 should challenge us to do real multiplexing of requests. I don't believe our existing hierarchy of pools deals well with the complexities of lifetime management of data in this multiplexed world, especially when you multiply that multiplexed nature of an http2 proxy (or reverse proxy) with its own outbound connections and requests. A while back I built two async-only applications backed with APR’s pools that handled a similar problem as to the one described above, and the APR pools were not only highly suited to task but were also key in making sure it all worked properly. In the first case we used libev, and in the second case we used libevent. Ideally I want to be able to use APR without having to prop it up with an external event library. If we can enrich the apr_poll library to the point where it gives us the full range of event functionality that will be ideal. Additionally there are 'new' things that we don't deal with today, like: * Server Push * Stream Prioritization * Flow Control integration into proxy use cases Things like flow control and stream priorities interact poorly with the output current filter API and model -- calling the next function with a brigade, even if it wants you to try again, every caller has to deal with these complexities of back pressure -- I'd love to have more open discussion about ideas here. Dealing with back pressure is the reality - the idea that you can blindly pass an arbitrarily large body of work to a downstream filter and not give that downstream filter the option to say “woah there, slow down” is where we suffered. I believe the API I proposed handles this, so far it works pretty well. http2 will be around for another 20+ years, I'd challenge us to think about it as the default case, and http1 as a fallback case that we still support well, but the architecture and APIs are optimized for the future case. I think it all begins with apr_poll (or it’s successor). Regards, Graham —
Re: Bash CVE-2014-6271 and CGI / HTTPD
On 09/25/2014 01:03 PM, Jim Jagielski wrote: I agree, but one-off, specific-case hacks like that are usually more trouble then they are worth, imo at least. What if we find another attack vector? Then we add another special case, etc... IMO, this is outside of httpd's realm to deal with... +1 Regards Rüdiger
