Mu [was: How worse is the Shellshock bash bug than Heartbleed?]
On 9/30/14, Georgi Guninski <guninski@guninski.com> wrote:
... I find this _much_ worse than the passive Heartbleed.
How worse is the shellshock bash bug than Heartbleed?
a simplistic "shellshock worse than heartbleed" is mis-characterization of the situation. first, this presents a vulnerability without context, by itself. in the real world, we care about vulnerability with respect to exploitation. usually many vulnerabilities are leveraged together in exploitation of notoriety. in the sense of best practice and conservative security posture, heartbleed could be worse by far. a strongly keyed, defense in depth surreptitiously bypassed via bleeding. e.g. bleed UDP DTLS VPN to access internal network, bleed intranet HTTPS for admin credentials to critical infrastructure services. the ability to send things to a bash shell, even restricted shell, even constrained behind application layers, was always seen as bad practice for security conscious configurations - insiders get shell, not untrusted inputs. last but not least, this is all bullshit speculation; risk is a perspective and shellshock or heartbleed is better or worse depending on what you're looking at. best regards, P.S. #langsec asked how long you earth humans will be exchanging risky bits with strangers. i channeled djb and bet on "Forever!". [c.f. http://cr.yp.to/talks/2014.07.10/slides-djb-20140710-a4.pdf "Making sure software stays insecure"]
On Tue, Sep 30, 2014 at 07:40:34PM -0700, coderman wrote:
On 9/30/14, Georgi Guninski <guninski@guninski.com> wrote:
... I find this _much_ worse than the passive Heartbleed.
How worse is the shellshock bash bug than Heartbleed?
a simplistic "shellshock worse than heartbleed" is mis-characterization of the situation.
first, this presents a vulnerability without context, by itself. in the real world, we care about vulnerability with respect to exploitation. usually many vulnerabilities are leveraged together in exploitation of notoriety.
in the sense of best practice and conservative security posture, heartbleed could be worse by far. a strongly keyed, defense in depth surreptitiously bypassed via bleeding. e.g. bleed UDP DTLS VPN to access internal network, bleed intranet HTTPS for admin credentials to critical infrastructure services.
the ability to send things to a bash shell, even restricted shell, even constrained behind application layers, was always seen as bad practice for security conscious configurations - insiders get shell, not untrusted inputs.
last but not least, this is all bullshit speculation; risk is a perspective and shellshock or heartbleed is better or worse depending on what you're looking at.
best regards,
P.S. #langsec asked how long you earth humans will be exchanging risky bits with strangers. i channeled djb and bet on "Forever!". [c.f. http://cr.yp.to/talks/2014.07.10/slides-djb-20140710-a4.pdf "Making sure software stays insecure"]
Might be wrong, but continue to disagree :) Suspect this is just the top of the shellshock iceberg: http://www.theregister.co.uk/2014/09/30/openvpn_open_to_shellshock_researche... OpenVPN open to pre-auth (in certain configurations). Btw, people scared by HB probably will get close to clinically paranoid if the next HB allows "write anywhere" ;) { :; } ;)
On 10/1/14, Georgi Guninski <guninski@guninski.com> wrote:
... Suspect this is just the top of the shellshock iceberg: http://www.theregister.co.uk/2014/09/30/openvpn_open_to_shellshock_researche... OpenVPN open to pre-auth (in certain configurations).
if you are using any of the up, down, ipchange, route-up, tls-verify, auth-user-pass-verify, client-connect, client-disconnect, or learn-address scripts with openvpn you are not operating in a security conscious manner. to reiterate, in case anyone missed it: exposing a shell to untrusted inputs is insanity. this is true even if you manage to make your environment variable sanitization apparently robust.
Btw, people scared by HB probably will get close to clinically paranoid if the next HB allows "write anywhere" ;) { :; } ;)
part of my intent was to convey that heartbleed easily leads to arbitrary exec; even if not directly so ala shellshock. so agree to disagree indeed; thus far heartbleed has medical pwnage and altcoin pilferage to credit, while shellshock is a farce of consumer crap and sloppy run yawn vulns; the mythical wide worm yet to materialize... due time will tell, of course! :P best regards,
On Wed, Oct 01, 2014 at 07:04:19AM -0700, coderman wrote:
On 10/1/14, Georgi Guninski <guninski@guninski.com> wrote:
... Suspect this is just the top of the shellshock iceberg: http://www.theregister.co.uk/2014/09/30/openvpn_open_to_shellshock_researche... OpenVPN open to pre-auth (in certain configurations).
if you are using any of the up, down, ipchange, route-up, tls-verify, auth-user-pass-verify, client-connect, client-disconnect, or learn-address scripts with openvpn you are not operating in a security conscious manner.
to reiterate, in case anyone missed it: exposing a shell to untrusted inputs is insanity. this is true even if you manage to make your environment variable sanitization apparently robust.
OK :) Tell this to djb, qmail local delivery was allegedly affected ;) Cheers
Btw, people scared by HB probably will get close to clinically paranoid if the next HB allows "write anywhere" ;) { :; } ;)
part of my intent was to convey that heartbleed easily leads to arbitrary exec; even if not directly so ala shellshock.
so agree to disagree indeed; thus far heartbleed has medical pwnage and altcoin pilferage to credit, while shellshock is a farce of consumer crap and sloppy run yawn vulns; the mythical wide worm yet to materialize...
due time will tell, of course! :P
best regards,
On 10/1/14, Georgi Guninski <guninski@guninski.com> wrote:
<codermange> rant'eth: .... to reiterate, in case anyone missed it: exposing a shell to untrusted inputs is insanity. this is true even if you manage to make your environment variable sanitization apparently robust.
OK :) Tell this to djb, qmail local delivery was allegedly affected ;)
even the best of us are only human. :/ reason #75,312 that email must die in a fire! (i'd also note there is no httpS://cr.yp.to/ ...) best regards,
On 10/1/14, Georgi Guninski <guninski@guninski.com> wrote:
... Might be wrong, but continue to disagree :)
i would note that by this time for heartbleed[0], Community Health Systems was already hacked a long week and a half. yet shellshock still shows muted impact. best regards, 0. CHS was hacked roughly a week after heartbleed disclosed, see official disclosure (to SEC) in august impacting 4,500,000 patients.
On Sun, Oct 05, 2014 at 12:35:51AM -0700, coderman wrote:
On 10/1/14, Georgi Guninski <guninski@guninski.com> wrote:
... Might be wrong, but continue to disagree :)
i would note that by this time for heartbleed[0], Community Health Systems was already hacked a long week and a half. yet shellshock still shows muted impact.
best regards,
0. CHS was hacked roughly a week after heartbleed disclosed, see official disclosure (to SEC) in august impacting 4,500,000 patients.
ok, i won't argue :) -- "Whenever people agree with me I always feel I must be wrong." - Oscar Wilde quote
participants (2)
-
coderman -
Georgi Guninski