f-

Honestly, I don't think it's been easier in the days of university mainframes. Today, it takes minutes to download, run, and brick new OSes in a VM; you have terabytes of free and easily searchable documentation and code samples at your fingertips; hardware is cheaper than ever; etc. It's pretty great.

My best advice would be, don't overthink it. Take one random thing apart, see how it works, and see if you can break it. Try digging into the inner workings of memory virtualization, or write a "hello world" bootsector in assembly, or figure out how syscalls happen and write your own that does something silly, or design a simple program that injects something into an ELF binary without using any higher-level tools. Or, perhaps, just browse random 2- an 3-section manpages and experiment with what you find.

Please be very careful when using less popular C/C++ image parsing libraries on anything that is user-controlled or that comes from the Internet.

Image, multimedia, and archive parsing are notoriously prone to security bugs. In fact, so are most other types of complex parsing. There are months of researcher work and decades of CPU time that went into auditing and fuzzing libraries such as libpng or libjpeg-turbo, identifying and fixing lots of vulnerabilities. The same isn't true for libraries with much smaller following, especially if their documentation doesn't contain any discussion of security risks and countermeasures taken.

Encoder? You'd probably want to try a decoder as the target binary if you want to make MP3s.

You can add instrumentation to binaries using DynamoRIO or pin. This isn't currently supported by afl-fuzz out of the box, although there's nothing that makes it fundamentally difficult.

Sure, it's even called that on the project page :-) It just uses an interesting fitness function that knows nothing about the underlying data format - essentially, "improve the edge coverage in this black-box binary".

The main problem with SAGE is that at least outside Microsoft, it exists just as a series of (very enthusiastic) papers :-)

So, while I suspect it's very cool, it's also a bit of a no-op for everybody else. It's also impossible to independently evaluate the benefits: for example, its performance cost, the amount of fine-tuning and configuration required for each target, the relative gains compared to less sophisticated instrumented fuzzing strategies, etc.

The Linux kernel and the core utilities needed for an user-friendly OS add up to a mind-boggling amount of code, written by thousands of hobbyists over the course of decades. That code base has the benefit of actually existing, being familiar to a lot of people, and (mostly) behaving in predictable ways that are consistent from one un*x-like system to another.

So in that sense, it's somewhat counterproductive to just say "somebody oughta rewrite this stuff", unless (like RMS) you're willing to dedicate a good chunk of your life to that mission - or think that your post will inspire somebody else to do the same.

Yup, unless you are doing something crazy.

Obviously wasn't a month ago (https://news.ycombinator.com/item?id=8432826), but yeah, it's not exactly fresh.

Batches of CVE numbers get pre-allocated to major players well ahead of any actual vulns being found, so that there is no need to individually request IDs from a central authority for, say, every single browser bug.

That happened here, the vuln itself is... um, around two weeks old.

This is an... odd submission. But I'm the guy who found this and the '78 one. To cut to the chase, run this command from within bash:

_x='() { echo vulnerable; }' bash -c '_x 2>/dev/null || echo not vulnerable'

If it says "vulnerable", you need to:

1) Immediately update bash to the latest version provided by your distro, or manually recompile with all the applicable patches from ftp://ftp.gnu.org/gnu/bash/ (look at bash-*-patches for your version).

2) Make sure that you have a more reliable way to stay in the loop on important security updates in the future, since most major vulns don't make it to HN - and this one is more than a week old.

...

If you're interested in what "CVE-2014-6277" actually is, or what that test does, check out my recent blog posts, probably starting with:

http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-...

I think there are quite a few people who do make a living by participating in vulnerability reward programs (well, not at $50 level, obviously).

Now, I have not seen too many people who would be doing it consistently for many years - simply because it gets tiresome. But it's the same thing for security consulting - at most consultancies, pentesters come and go.

If you followed some common-sense advice [1], you only needed two patches: the original one as a stop-gap measure for the original RCE on September 24, and Florian's prefix-adding patch that came out shortly thereafter (but has taken some time to appear upstream).

Now, I'm a bit stumped how any obvious variant of the CVE-2014-6271 or CVE-2014-6278 RCE payloads could lead to accidental code execution somewhere else, since they generally produce a parser-breaking syntax error when executed outside an env-encoded function definition. Also, because of an unusual fixed-string prefix required to carry out the attack, there is not a lot you can really do to avoid any half-baked IDS/IPS. Anyway, for the sake of my idle curiosity, I secretly hope that Alex shares the buggy line of code, even though that's unlikely =)

[1] http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficia...

You essentially can't evaluate that in isolation (looking at their past interactions with the infosec community may help).

It gets better: you can't even depend on the large players generally getting it right. If a large organization makes a bad decision with their first infosec hire, it's not a self-correcting problem - the next hires will be cut from the same cloth, and unless something blows up, almost nobody will know.

They applied the unofficial one. The official one uses a different suffix.

Using env may be slightly more portable if you're using an exotic login shell that doesn't support the "FOO=1 program" syntax - say, tcsh.

But for most part, it's probably just people copying-and-pasting stuff without really figuring it out what it does. For example, compare "exploit #1" and the supposedly different "exploit #3" on shellshocker.net.

Yup, as of yesterday, they are shipping the unofficial patch. I added a simple command to test if you're patched at the bottom of the blog post.

It should work on top of the original patch with 4.3. Don't omit 025.

Since the post is relatively non-technical, I'd like to underscore that there are substantial concerns with the original and the followup patch, because with or without it, the underlying bash code parser is still exposed to the Internet. Nobody has posted an RCE vector that would be universally bad for the patched version, but several people have already identified "hmm, that's unexpected" types of global side effects when attacker-controlled strings are parsed as functions by bash. More is likely to come.

As of today, based on our conversations on oss-security, there is a third, unofficial patch that takes a much saner approach of isolating exported functions in a distinct namespace:

http://www.openwall.com/lists/oss-security/2014/09/25/13

Especially in high-value or high-risk scenarios, you may want to give it a try. And if you're interested in the reasons why the original patch is problematic, check out:

http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-b...

There is an unofficial patch that takes a much more reasonable approach:

http://www.openwall.com/lists/oss-security/2014/09/25/13

I helped draft the original blog post :-) To clarify a bit more and help folks evaluate their individual risk, it's worth noting that the impact is limited to a fairly specific scenario.

In essence, you needed to have a non-native document format uploaded to Drive without converting it (PDF is a good example); explicitly share this document with others using a particular setting ("anyone with the link"); and then preview it in the web UI and follow an outgoing HTTPS link (HTTP wouldn't be a problem).

Similarly to CSP, onload and onerror are not the only ways to pull it off. The effect of successfully or unsuccessfully loading images or scripts can be usually inferred without that; for example, images have dimensions that, even if you take away the ability to read them directly, can be inferred from the changes to the layout of the nearby elements.

Such attacks are interesting, but the CSP part is a red herring to some extent; we had this problem without CSP and the issue is mostly that nobody has any good ideas on how to get rid of this class of attacks without breaking the web:

http://lists.w3.org/Archives/Public/public-webappsec/2014Feb...

I don't know why they wanted the info (and it was fairly dumb of them to try). Nevertheless, they saw some practical value in it, so did others.

Well, say... http://www.theregister.co.uk/2010/12/03/browser_history_snif...

Probably, but in the end, it doesn't matter: there is a single, widely archived mailing list that almost everybody knows about.

Outside the several mailing lists we have, there's nothing resembling a central repository of security research and industry gossip. It's possible that it all could be done better with a custom web forum, a VIP room on Chatroulette, or a well-designed UUCP dead-drop - but so far, despite many attempts, nobody really succeeded with that.

Plus, F-D is awful mostly because it's a fairly accurate mirror of the security community itself (and certainly many of the web forums I have seen). More often than not, this is what makes the headlines - not a novel sandbox escape exploit that bypasses kSLR.

I've been active in the infosec community for ~18 years, probably as one of its more prolific members at times - and similarly to Thomas, I'm not really sure I buy this argument. I don't want to cross-post the entire thing, but here are my thoughts in response to similar posts on /r/netsec:

http://www.reddit.com/r/netsec/comments/20sxd2/full_disclosu...

Well, we have an official reward program with published criteria, and to a large extent, it's just a matter of reputation: if we were unfair or stingy, it would be a very short-sighted strategy.

That aside, having another party getting advance knowledge about the bugs is risky: it just gives bad actors a juicy target to infiltrate to get a steady supply of 0-days.

It's hard to win bidding wars with nation states. It's even harder to make such victories matter: after all, they can always switch to doing security research and exploit development in-house.

Instead of trying that, we're catering to two groups of researchers:

1) Those who are not comfortable with the idea of selling weaponized exploits to the highest bidder for unspecified offensive purposes, and

2) Those who like to find bugs, but don't want to spend days or weeks to develop reliable, weaponized exploits for resale.

As it turns out, there are thousands of extremely prolific researchers who fall into these buckets; the number of "black market" players is much lower than that.

The reason why all of this matters is purely probabilistic: all this scrutiny limits the number of remaining vulnerabilities that can be leveraged for nefarious purposes, and limits the lifespan of any already-known 0-day bugs.

Now, having said all that, your comment is more applicable to vulnerability reward programs - which this isn't :-)

In essence, we have a reward structure that we think is internally consistent, attracts the right sorts of research, and makes an optimal use of our resources - and we try to apply it fairly.

Here, we handled the communications poorly, and I think it's OK to call us out on that. In fact, I think it would be wrong to offer a reward in hopes of buying silence from the reporter :-)