Hacker News Reader

Comment by laumars | Hacker News Reader

Seems like it was created a month ago today:

    Date Entry Created: 20140909

Also, there's been a few more patches since (bash43-030): http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

View on HN

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.

Ahh I didn't realise that. Thanks for the correction.

Do you know if the more recent patches, {27..30}, are also vulnerable to this CVE?

I think 27 is first one without any of these issues. That's what "pkg audit" on my freebsd box is telling me at least. Currently on 27 and it doesn't show any issues. They could just be out of date though.

Patches 28-30 fixed underlying bugs, but 27 closed the loophole that made them accessible from the outside. So if you have 27 but not the later ones, you are safe from any currently known attack method from "outside" bash; you can still trigger unexpected code execution from the command line or a shell script, but this cannot be done remotely anymore. Theoretically, these bugs could be used as part of another attack, so it's wise but not urgent to patch them anyway.

Seems like an anachronism that might be worth updating. Surely just give the CVE number when the vuln gets submitted, eg as a date+index. Is it difficult to issue IDs on demand for some reason? If multiple bugs are submitted together then whatever app that doles out the CVE numbers could give them the same date and different indexes to indicate this. Co-terminus bugs could be treated as linked.

Reply on news.ycombinator.com