BashBleed/ShellShock - My heart is bleeding - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > BashBleed/ShellShock - My heart is bleeding

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Soon, the entire Internet will be mining Bitcoins.

evol262 posted:

CGI calls for metavariables. These are almost always done as environment variables. FastCGI and other app servers avoid this in different ways, but anything that's plain CGI which calls out to system() or a shell, ever, is vulnerable.

Why even do this instead of calling setenv?

# ¿ Sep 26, 2014 01:36

Adbot: ADBOT LOVES YOU

# ¿ Apr 23, 2024 10:36

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

evol262 posted:

setenv where?

By the time you can setenv, the environment has already been parsed and you're dead.

I guess I'm not really grasping how this works. I was under the impression this required setting environment variables through a call to the shell like system(), which using something like setenv would avoid, or is that not true?

# ¿ Sep 26, 2014 01:58

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Random thought: Might this (and Heartbleed) be a counterpoint to the idea of security through obscurity being bad, since something like this happening on a closed platform would probably have been either quietly patched out during a maintenance update or patched out as a completely non-specific vulnerability instead of being announced to the whole world with instructions on day zero?

# ¿ Sep 26, 2014 06:10

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Dr. Jackal posted:

While the release for this might have been poorly managed, if this was a closed source bug we may have never found out about it.

It's possible that attackers would have never found out either though.

I don't know how this could have been managed better though with an open-source program, which is the problem. It's not possible to release a source patch without revealing the problem, whereas a patch of a closed binary would probably get lost in a sea of other updates released at the same time, allow the embargo to extend for a much longer period while still distributing the fix, and reveal much less information about the specific vulnerability in the end.

The only way I can think of to discretely update something like Bash would be to, say, come up with an excuse to refactor the surrounding system to disguise the motive.

OneEightHundred fucked around with this message at 07:32 on Sep 26, 2014

# ¿ Sep 26, 2014 07:10

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

evol262 posted:

Additionally, "refactoring the surrounding system" to avoid disclosing major security problems is unethical. You're either proposing suggesting an RFE or code rework which gets a ton of (suspicious) mailing list traffic about its implications or a closed list discussing what to do about problems, which is antithetical to open-source ideals, obvious, or both.

What's ethical is to minimize the damage done, and I don't really care for open source ideals if they aren't to that end either. The only real question is whether it would actually accomplish that goal or not.

# ¿ Sep 26, 2014 09:59

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

evol262 posted:

It's also unethical, but you clearly don't care about that.

I'm hardly the first person to question whether full disclosure is ideal. I recall seeing one security researcher at some major security company basically flipping on the issue and suggest that public disclosure is largely enabling the problems that it claims to solve and recommended only disclosing to "responsible" parties, or not disclosing it at all if the vulnerable systems are due to be retired anyway. Retiring bash isn't realistic, of course, and full disclosure is certainly better than vendors not fixing the problems, but this is a question of what kind of information should go out when the problem IS being fixed.

quote:

Again, ethics may not be a big deal in the games industry.

I'm asking about this because I personally care about security quite a bit and would like to understand why this would or wouldn't be a good idea. It would be nice to get that information instead of this pointless "my dad can beat up your dad" thing you keep harping on, as if the field I'm in has anything to do with answering that question, and you're barking up the wrong tree anyway since the vast majority of my background is in an engine modding community with a deeply-ingrained culture of validating everything and fixing security issues immediately.

OneEightHundred fucked around with this message at 18:38 on Sep 26, 2014

# ¿ Sep 26, 2014 18:21

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

evol262 posted:

Yet again, responsible disclosure was practised, but the scope of the vulnerability was larger than anticipated. distros@ is disclosure only to '"responsible" parties'

I can't find the article so I have to paraphrase, but in context, it was explicitly in contrast to public disclosure where the information would wind up in the hands of malicious parties as well. I found one that at least contains similar sentiments:
http://broadcast.oreilly.com/2009/01/responsible-disclosure-is-irre.html

The core issue is that the overwhelming majority of attacks are not via zero-days, but via vulnerabilities unveiled by security researchers and deployed against users that haven't patched. The same article suggests that covert patching might be a good idea too, so I guess there's your answer to whether anyone would be consider it to be ethical.

It's probably better than vendors ignoring everything, sure, but the question is if it's possible to fix an issue without drawing attention to it.

evol262 posted:

It would open you to lawsuits (when some large bank or govt agency was left in the dark about what the problem was and how it occurred, then owned because they didn't update)

On what grounds? I can't find anything suggesting that nondisclosure has any impact on liability, and I can find plenty of people complaining about vendors not being liable at all, especially if they put liability waivers in the EULA like they always do. If liability waivers were disallowed by statute, then OSS would be obliterated.

# ¿ Sep 28, 2014 02:57

Adbot: ADBOT LOVES YOU

# ¿ Apr 23, 2024 10:36

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

evol262 posted:

Responsible disclosure is the context.

I specifically said that it was advocating secrecy and that "responsible" was a paraphrase, but it's hearsay anyway, so it's probably not worth arguing. The Viega article expresses most of the sentiments anyway, and the factual issue is the same regardless of who's saying it: Public disclosure as currently practiced causes massive collateral damage.

quote:

Whether or not one person considers covert patching OK has no impact on whether it's ethical.

And what makes it unethical? You've written off the "greater good" and effectiveness as having anything to do with it, so what's left?

quote:

misrepresentation (ala covert patching)

Replacing a component without explaining every decision that led to the replacement in intricate detail is not making a false statement.

# ¿ Sep 28, 2014 07:29

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > BashBleed/ShellShock - My heart is bleeding