But mainly, as I clearly stated above, what you are missing with other products is that you don't have the option of dual-booting AND, at the same time, running the SAME foreign OS install in VMWare or the like. If you want to do that you are stuck with 2 different foreign OS installs, and your files won't be in sync.
I didn't say dual-booting was unique to Mac. Read it again. What I wrote was that it's BETTER. Especially if you have VMWare. While that's a third-party product, it enables you to do what other OSes won't do, even with VMWare.
Without specifying which VMWare product it is a bit difficult to see what you are getting at - workstation or full ring-0 hypervisor like ESX ?
If you mean just the option of booting a virtual disk (vhd) which you can also use in an emulator, Windows has had that for 5 years (since 7) without needing a third party emulator (VirtualPC from MS).
If you mean having the option of booting a vhd and having also a full hypervisor that can run that vhd as a virtual machine, built into the OS, Windows has had that for six years on the server OS versions, and two on client (Windows 8) - Hyper-V is built in along with native-boot-from-vhd.
There are also Linux options for both boot-native-from-vhd and built in hypervisors.
So, struggling a bit to see what it is you think other OSes can't do ?
The whole article is de-indexed. That is the only way it can work - the required form of complaint is that the information is inaccurate / irrelevant / etc., i.e. the complaint is that the information should be "forgotten", not that any particular search term should not lead to it.
Wrong. Already there have been cases where the main subject of a removed article was publicly accused of having it removed, only for it to turn out to be a commenter on the article that wanted their comment forgotten. Since the ruling only affects the search index and not the actual page, the whole article will have to be de-indexed just to forget one comment. There could be a lot of different commenters on one page.
Yeah, but the fact that you have to mess with and configure each component individually and manage all the dependencies yourself means you know what is going on rather than have some magic uber-daemon figure out what it thinks you want and then do something, but you have no idea what it actually did when it goes wrong.
If the numerous people reviewing Bash, from multiple companies, and disciplines didn't find the issue with the first patch, then how would Microsoft with a far more limited set of people looking at the code be able to get the same kind of patch correct the first time and get all the corner cases figured out and fixed before releasing the first patch?
Because they have a "far more limited" team full of security specialists. Some (maybe all) of the later bugs were found using standard fuzzing tools, which should have been part of the test process the first time, as soon as the parser was found to be broken once on non-standard input. In fact it should have been picked up, whilst under embargo, that the whole idea of parsing code out of untrusted input was a security hole that would need to be patched (as it eventually was), even not-security-experts with some idea about security could have predicted that (as I did - http://slashdot.org/comments.p...)
I'm not saying the Bash devs had 1 million eyes on this; but they certainly had a few hundred if not a thousand or so in total.
During the embargo, really ?
Agreed - kinda. The main point of the origin of this thread (article?) was that F/LOSS software could not deal as well as proprietary software; that somehow the proprietary vendors could do better with these kinds of bugs - both catching them and responding to them.
Actually the article doesn't say that proprietary is any better, just that FOSS hasn't turned out to be as good at it as people were assuming (many eyes bugs shallow etc.).
But here's the kicker - there is a similar exploit for cmd.exe. It's yet to be patched.;-)
cmd.exe parser has a bug, or maybe a feature. bash parser had a bug, or several, or maybe a feature.
Big big big difference is that cmd.exe doesn't execute, or echo, or parse, all its environment variables at startup - that is the actual bash shellshock vulnerability (not the various parser bugs), and cmd doesn't have it. No one has yet found an exploit for this cmd.exe bug, let alone a remote one.
I didn't say MS was better, I said the bash response was poor, and the poster I replied to couldn't possibly have had fixes in place within minutes as claimed.
Oh, and in your argument "up to 30 days" suddenly becomes "taken 30 days" - actually if bugs come in uniformly distributed in the 30 day cycle then average would be 15 days, or lower since sometimes they do go out-of-band.
Plus, the second (and third and fourth and so on) patches are only needed if the first (and second and third.,.) one is inadequate and not properly tested. Maybe MS are just as bad at that too, but the developers of Bash were certainly not good at it.
1. no one is paying for them (or at least not enough to make a difference and catch stuff like heartbleed and shellshock) 2. auditing existing code doesn't "scratch an itch" for anyone on the hobbyist side
Closed source companies like MS have to weigh up costs of security auditing vs. cost of reputational damage of getting it wrong (i.e. if you think safety is expensive try having an accident). For a long time, MS was so secure as a monopoly that the reputational damage wasn't worth them worrying about - that isn't the case now, and they are better at security than they were, but they have a very large legacy mess still to clear up.
For open source companies, the reputational damage is spread or lands elsewhere (shellshock is a GNU bug not a Linux bug or a RedHat or Debian or...), so there is even less incentive. Your competition benefits equally from your auditing but you take the whole cost. Therefore it will need collective funding by competing companies - which is always a lot harder to organise.
How did you fix them in minutes when it took several days for correct patches to come out, for entirely predictable reasons (laughable approach of trying to find and fix all bugs at once in a parser never designed to be secure, when the real issue is that it should never be being fed untrusted input) ?
To my mind, that is the biggest failure of open source / free software in this case - 20+ yr old bug / insecure-feature in an obscure corner of a system never designed for today's threat environment - forgiveable - responsible disclosure, working with maintainers under embargo - good - publication along with a patch that was broken again within hours if not minutes - fail - everyone and his dog then panic-issuing further patches for one parser vulnerability after another before eventually someone (actually more than one different approach) fixes it properly the way it should have been done in the first place - spectacular fail
There is good engineering and engineering a successful product. Edison was much better at understanding the latter, he also understood and played the patents system. He was in the end by far the better capitalist / businessman, hence he won, financially, and winners write the history books.
Before writing Tesla down as always the great engineer who never got successful, it is worth remembering that he did make a fortune (tens of millions in today's money) from his AC patents before he gave up on the royalties, but he died a pauper because he blew his fortune self-funding research into ideas that were much less good - too confident in his own promised results, he sunk all his money into ideas that just didn't work.
Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet
For some, the ability to run their own code on a server with high bandwidth outward connection to the internet is all the power they need/want. If the server is an authorised mail source for a domain (e.g. spf) then so much the better. If the user has access to some writable disk space that can be used to host some interesting files, then there are uses for that. If the user can read the web site source or config files that may have value in itself or may lead to further penetration - but I'm sure you've never seen DB user/pw in the source for a production website, ever ?
C. Like it or not, the bitcoins represent evidence. Seizing evidence is par for course in any criminal case.
Is selling the evidence off before the trial (which it was seized to be used in) also par for the course ? What happens to seized evidence after a not-guilty verdict - or do certain people already know that is not a possibility ?
Nothing was stopping the angels either, per Genesis 6-4 "when the sons of God came in unto the daughters of men" and begat the Nephilim (or were the Nephilim depending on your translation). Enoch appears to make clear they are angels, but Enoch is apocryphal so you may or may not believe it enlightens the story in Genesis. It matters not though, because the story _is_ in Genesis which is canon, and whether the "sons of gods" (or Enoch's Watchers) are angels or aliens, they are clearly not-men but are capable of interbreeding with "daughters-of-men" and producing a race of giants (Nephilim).
As regards opening up a whole new mess, all of this is post-Eden and pre-flood, man can always complain to God: "you said I had dominion over everything so what are these more powerful beings doing taking all the good looking girls" , and God will say "yeah and ? Can I remind you that was back in Eden when I also told you not to eat the ****ing apples ?".
At least with Linux, if a security hole is found (and made public or released to experts in the security community or to the relavent developers or whatever), the number of people who are able to investigate and fix the hole (and make official or unofficial fixes available) is (in most cases) significantly larger than the number of people who would e able to deal with issues in Microsoft code. And the Linux guys can have patches out much faster (and they can get into distros fairly fast too)
There is a flip side to that, which is that too many cooks with no common management may royally spoil the broth, which is what has happened.
When found, this was embargoed and should have been fixed under embargo, properly. Instead, someone pushed out half-baked patches that were proved to be still vulnerable within hours (if not minutes), and by then everything was public. So now we have everyone and his dog patching in panic mode, three, four or more(?) sets of patches now, with each one still proving vulnerable, because collectively we blew our chance to fix it (and test it) properly the first time.
The eventual fix will have to be to stop playing who-finds-the-parser-bugs-first and accept that the whole feature is a security hole and needs to be removed or radically changed - something that could and should have been predicted at the start. There are various patches flying around now that do just that, probably in different incompatible ways. Those changes will, inevitably, break some stuff - and of course we could have looked and tried to figure out the extent of that, and mitigated the effect and been ready with the announcement, if it were still under embargo, but we blew that chance.
I am all for saying that the open source development model is better - but this really is not the best example to use to illustrate it, in fact it's already heading into embarrassing farce territory.
I can't imagine the stupidity of these security folks or programmers. bash is not remotely, remotely exploitable. Hint, there a program that listened to a network connection, then, it decided to try and pawn off security and trustworthiness to another program. That trust was misplaces and that program is wrong.
If you accept bash commands on a network connection and feed them to bash, then you are an idiot, full stop. Now, if you validate the arguments, the format and the content of the command, for example, you allow two formats true, false. Then, reasonably you can call bash to run those two commends. What you can't do is accept any arbitrary string and pass it to bash.
Problem is that in unix the way is for tools to call other tools, and the shell is so pervasive it could be anywhere. How do you actually _know_ if you are calling bash ?
* If you run/bin/sh are you calling bash ? Should you always check first ? Can you even check ? * same for calling system() etc. * If you run any other executable should you always check whether it is a script first ? Can you even check always ?
And this applies all the way down the pipeline, parts of which may be user/admin configurable.
Accept what you prove is trustworthy. Be willing to fix it, and claim responsibility when you are wrong.
No meta characters in environment variables, trivial, not meta characters in arguments, trivial. The argument should be a number, 0 to 255, check it _first_, then pass it.
Where in the pipeline ? What if you don't _know_ what the data is supposed to be at this point (only some other tool might do, down the pipeline, how then do you prove it is ok ? What does "no meta characters" mean in the context of an HTTP Cookie, or an email subject line ? - it is meaningless, arbitrary text is valid data in either case.
I thought we learned this with all the sql commands from the network bugs. We seemed to do the right thing for them, why do they have it so wrong this time around?
What we learnt was to properly sanitize and/or quote text that was executed as SQL commands. At the point that we knew it was going into a SQL command. Your web server doesn't know what you are going to use each form field for, "Robert'); DROP TABLE Students" is perfectly valid as a subject for a forum post, but as a user name in a SQL command it needs quoting first. The web server can't quote it, the cgi script or whatever down the line needs to quote it - if and when it gets used in SQL. Now, the web server also does not know and should not need to know what language a cgi script is in, but if it is bash, then bash will execute data as code before the script has chance to verify it.
This generalises to the whole pipeline - any caller may not know what the data it is passing down the pipeline in the environment (or otherwise) actually _means_, or what is valid/non-valid/malicious. Such determination can only be made by the callee that understands the data - but bash may execute it before it gets there.
Let's assume you are right and we can compare with SQL Injection. With SQL Injection we learned we had to properly quote data before feeding it into SQL, and fix all the places we do that. So, with bash injection, now that we know about it, to do the same we would need to sanitize / quote all environment variables whenever we call bash. Except we don't know when that is (see above), so you really mean that every program that execs any other program or feeds into any other program in a pipeline where that program might possibly be a shell script, needs to quote environment variables. That is just about every unix program ever written (and, er, where/when are you going to unquote that data ?).
Or we fix bash, the program that is actually blindly executing data as code.
Worth listening to sales, sometimes there is value in what they say, and you need them on side - it isn't fun (or good for job security) writing great software that they can't or won't sell. The suggestion is good as far as it goes but I would say it isn't as simple as that.
Unless you are open source, your dev teams bug trackers should be their area and confidential to them, they may not all be commercially aware customer facing people, they may speak their mind in choice terms about some bug reports, and you shouldn't have to be constantly afraid of that turning up in front of the customer. It isn't just dirty laundry, it's the whole cleaning process and every dirty comment you make whilst doing it.
Then, each customer has their own issues which should be confidential to that customer (and you). Some issues may not be bugs but embarrassing customer mistakes, and customers _will_ (sooner or later) put information into an issue that is commercially confidential, personal information (data protection) or security related. Sometimes this is necessary - bugs may only be tripped by certain data, and it isn't the customers job to determine the general case, it's your job when investigating. Support and dev need to understand that issues are private to a customer, but also sales so they can explain it positively to prospects: "can we look at your issue list ?" "we can't show you customer reported issues because we treat them as confidential to that customer - we believe customers should be able to report exactly what happens which may include their data, rsther than be required to create a general test case". Customer issue lists are not a concern of sales but rather account management - the customer account manager may be in sales, but if so it is a different role they are doing.
Then you (maybe) have general issue list(s) that are visible to all customers - effectively a dynamic tracking view of what will be in the release notes (see below). You need to re-create issues here from the customer reports - not just blindly copy customer report - and really these should be general cases not just what the customer reports. E.g. customer reports issue with Web UI display of account named "P&O", you establish it's an issue with ampersand, and what you report to all customers is that there is an issue with ampersand, otherwise you risk reporting too narrow a bug and exposing customer confidential information. Not every issue will make it to this list, only if it is of general concern, and issue that affects a configuration only used by two customers who have already been informed has no relevance here. I still see little value in this list being public beyond customers, but it should be expected that it might become public at some point (possibly via a customer) and information in it should be written accordingly, at very least it is available to all customers. For these reasons sales may sometimes be involved in decisions as to what goes on this list.
For betas and dev builds etc., maintain separate lists and give access only to those customers who are running those versions, make them feel special, but also your SLAs etc. will be different for non-production versions and this helps keep that clear.
Finally, release notes - fixed issues and known outstanding issues. If you provide public downloadable demos, or you provide demo installs to sales prospects, then these need to come with release notes, so these documents go (at least) beyond your customers. For that reason you don't just dump (any of) the lists above into the release notes, each issue needs to be vetted for inclusion (see above for relevance, plus you want to inform not overwhelm) and rewritten to show your customer service in a positive light - this is effectively part of your shop window.
I would recommend trying to get sales (and maybe marketing) involved in reviewing (and editing) release notes, they are technical documents that need to be customer relevant and readable, sensitive to commercial needs and priorities, and hen
Check your distro. Believe RedHat at least have newer allegedly more complete patches - although there are also posts saying you'll need a support contract for some older versions of RedHat.
My guess is that initially this was embargoed while GNU/FSF guys "fixed" it, but when we find out fact that the fix was no good everything is already public so now everyone downstream is trying to fix it themselves as fast as possible - RedHat etc. may do their own without waiting for upstream. It's now that you find out how good your support is, from whoever you paid for it or from the guys who work for free if you paid no one.
If you want the diy approach, personally I would look at the initial patch for where the offending code is and rip out the entire "feature", I suspect very few scripts will break.
I think the bigger than heartbleed comments might be a bit overblown. If you're running CGI and your web server is running as root, you probably have a serious problem. Otherwise, it's just a PITA when you have other things to work on. Can anyone tell me why the script kiddies are scanning 23? I haven't seen an open telnet port in years. From all the reports I've read, about the only things vulnerable are web servers running CGI which was pretty vulnerable before.
ssh is also vulnerable (often configured to pass TERM and maybe LC_*) Git repos using locked-down ssh - vulnerable dhclient - vulnerable CUPS - vulnerable
Those are just the ones we know so far.
It is different to heartbleed, and it could indeed get bigger. Heartbleed required zero effort to get the data but then needed some luck and some work to find keys or login info within it. Manual work required before you could break into a system.
ShellShocked on the other hand is direct, trivial, remote code execution. Attacks can easily be fully automated - it is wormable, trivially. The question now is not whether or not fully automated worm attacks will happen or when - they already are - it is how many servers they will get.
And that is all before we start looking at all the embedded Linux out there that may have bash, and often have cgi. It may take longer to find exploit vectors for those, but it will also take longer to patch, and some may not be patchable. Add in to the mix that small business / home routers often also run dhcp servers, and that dhclient is vulnerable, and a router compromise can open up any unpatched client machines inside the firewall.
No one knows how big this _will_ get, but it _could_ be bigger then HeartBleed, easily.
So... unless your CGI script is extracting a header field and feeding it to a bash script... you should be okay in terms of HTTP requests with this in their header?
Keep your head in the sand, it's less scary that way.
Or realise that your CGI server feeds headers to your CGI processes in environment variables, because that is how CGI is supposed to work, and that it isn't just your CGI script it is every single process it starts (all children and descendants) that must not be a shell script and must not use system() etc. Perhaps then also note that CGI is just one vector that happens to be being attacked right now and there will be others, some we probably don't know about yet.
Or you could assume you are vulnerable and patch bash, or remove it.
Your web server might be responding with a 200 response code, but that's just because whatever the URL requested is, is being successfully sent.
Thoughts?
Correct - no need for attacks to cause any error at all. May be possible using an http header you aren't logging at all, giving you no way to detect it.
However, this has nothing to do with users on your box maybe trying to do privilege escalation with this bash trick. But... this isn't a privilege escalation trick - the user shouldn't have any more access to the system than he would have with running the commands directly, right?
Find a setuid script or setuid program that somewhere uses the shell and it's a privilege escalation too. Such things _should_ be very rare by now, but not impossible that some still exist.
1. the first fixes, within 24 hours of announcement, didn't actually fix it fully - in fact I suspect it will still be exploitable in some way or other until the "feature" of treating environment variables as code is removed completely 2. providing an incomplete fix may be worse than taking a bit longer to properly QA the fix - a lot of admins may believe they have patched this based on the first announced vulnerability tests and the first set of patches, but in fact they are still vulnerable with a trivial change in the malicious bash code 3. it was less than 24 hours after first being made public - this may be entirely unrelated to when it was first found
We have no idea who found it first or for how long it may have been used covertly (did NSA etc. know of heartbleed before public knowledge ?) We don't know what prompted someone to be looking for problems in code that hasn't changed for 20+ yrs. It is so trivial to get remote code run with this bug (no unexpected new process or login or errors) that I doubt it will trip any intrusion detection systems. If you can use an http header that isn't logged, then you could run code on the server and extract information and it may be completely undetectable.
Something else we don't know is how the FBI really got the Silk Road server to cough its real IP address. The FBI claim they put "miscellaneous characters" into the login form and it just happened to send the address back. You can believe that if you want. It may or may not be related (I have no idea about the silk road server setup), but a handful of days after the FBI put their story out someone is looking for security holes / bugs in very old bash code. Maybe there was no trigger and they just happened to get bored one day and decide that looking for bugs in bash would be fun. Or maybe there is more behind this than we know.
Slashdot Mirror
But mainly, as I clearly stated above, what you are missing with other products is that you don't have the option of dual-booting AND, at the same time, running the SAME foreign OS install in VMWare or the like. If you want to do that you are stuck with 2 different foreign OS installs, and your files won't be in sync.
I didn't say dual-booting was unique to Mac. Read it again. What I wrote was that it's BETTER. Especially if you have VMWare. While that's a third-party product, it enables you to do what other OSes won't do, even with VMWare.
Without specifying which VMWare product it is a bit difficult to see what you are getting at - workstation or full ring-0 hypervisor like ESX ?
If you mean just the option of booting a virtual disk (vhd) which you can also use in an emulator, Windows has had that for 5 years (since 7) without needing a third party emulator (VirtualPC from MS).
If you mean having the option of booting a vhd and having also a full hypervisor that can run that vhd as a virtual machine, built into the OS, Windows has had that for six years on the server OS versions, and two on client (Windows 8) - Hyper-V is built in along with native-boot-from-vhd.
There are also Linux options for both boot-native-from-vhd and built in hypervisors.
So, struggling a bit to see what it is you think other OSes can't do ?
The whole article is de-indexed. That is the only way it can work - the required form of complaint is that the information is inaccurate / irrelevant / etc., i.e. the complaint is that the information should be "forgotten", not that any particular search term should not lead to it.
Wrong. Already there have been cases where the main subject of a removed article was publicly accused of having it removed, only for it to turn out to be a commenter on the article that wanted their comment forgotten. Since the ruling only affects the search index and not the actual page, the whole article will have to be de-indexed just to forget one comment. There could be a lot of different commenters on one page.
Yeah, but the fact that you have to mess with and configure each component individually and manage all the dependencies yourself means you know what is going on rather than have some magic uber-daemon figure out what it thinks you want and then do something, but you have no idea what it actually did when it goes wrong.
[or is that systemd, i forget...]
we already have those - look at all the 'bots posting on here for starters...
The rationale was probably to rack up charges, if the machine was not in use at the time, might as well use it.
CT _scanners_ of course are pretty expensive, be interesting to know how they decontaminated it, if they did.
If the numerous people reviewing Bash, from multiple companies, and disciplines didn't find the issue with the first patch, then how would Microsoft with a far more limited set of people looking at the code be able to get the same kind of patch correct the first time and get all the corner cases figured out and fixed before releasing the first patch?
Because they have a "far more limited" team full of security specialists. Some (maybe all) of the later bugs were found using standard fuzzing tools, which should have been part of the test process the first time, as soon as the parser was found to be broken once on non-standard input. In fact it should have been picked up, whilst under embargo, that the whole idea of parsing code out of untrusted input was a security hole that would need to be patched (as it eventually was), even not-security-experts with some idea about security could have predicted that (as I did - http://slashdot.org/comments.p...)
I'm not saying the Bash devs had 1 million eyes on this; but they certainly had a few hundred if not a thousand or so in total.
During the embargo, really ?
Agreed - kinda. The main point of the origin of this thread (article?) was that F/LOSS software could not deal as well as proprietary software; that somehow the proprietary vendors could do better with these kinds of bugs - both catching them and responding to them.
Actually the article doesn't say that proprietary is any better, just that FOSS hasn't turned out to be as good at it as people were assuming (many eyes bugs shallow etc.).
But here's the kicker - there is a similar exploit for cmd.exe. It's yet to be patched. ;-)
cmd.exe parser has a bug, or maybe a feature. bash parser had a bug, or several, or maybe a feature.
Big big big difference is that cmd.exe doesn't execute, or echo, or parse, all its environment variables at startup - that is the actual bash shellshock vulnerability (not the various parser bugs), and cmd doesn't have it. No one has yet found an exploit for this cmd.exe bug, let alone a remote one.
I didn't say MS was better, I said the bash response was poor, and the poster I replied to couldn't possibly have had fixes in place within minutes as claimed.
Oh, and in your argument "up to 30 days" suddenly becomes "taken 30 days" - actually if bugs come in uniformly distributed in the 30 day cycle then average would be 15 days, or lower since sometimes they do go out-of-band.
Plus, the second (and third and fourth and so on) patches are only needed if the first (and second and third.,.) one is inadequate and not properly tested. Maybe MS are just as bad at that too, but the developers of Bash were certainly not good at it.
There aren't because:
1. no one is paying for them (or at least not enough to make a difference and catch stuff like heartbleed and shellshock)
2. auditing existing code doesn't "scratch an itch" for anyone on the hobbyist side
Closed source companies like MS have to weigh up costs of security auditing vs. cost of reputational damage of getting it wrong (i.e. if you think safety is expensive try having an accident). For a long time, MS was so secure as a monopoly that the reputational damage wasn't worth them worrying about - that isn't the case now, and they are better at security than they were, but they have a very large legacy mess still to clear up.
For open source companies, the reputational damage is spread or lands elsewhere (shellshock is a GNU bug not a Linux bug or a RedHat or Debian or...), so there is even less incentive. Your competition benefits equally from your auditing but you take the whole cost. Therefore it will need collective funding by competing companies - which is always a lot harder to organise.
How did you fix them in minutes when it took several days for correct patches to come out, for entirely predictable reasons (laughable approach of trying to find and fix all bugs at once in a parser never designed to be secure, when the real issue is that it should never be being fed untrusted input) ?
To my mind, that is the biggest failure of open source / free software in this case
- 20+ yr old bug / insecure-feature in an obscure corner of a system never designed for today's threat environment - forgiveable
- responsible disclosure, working with maintainers under embargo - good
- publication along with a patch that was broken again within hours if not minutes - fail
- everyone and his dog then panic-issuing further patches for one parser vulnerability after another before eventually someone (actually more than one different approach) fixes it properly the way it should have been done in the first place - spectacular fail
There is good engineering and engineering a successful product. Edison was much better at understanding the latter, he also understood and played the patents system. He was in the end by far the better capitalist / businessman, hence he won, financially, and winners write the history books.
Before writing Tesla down as always the great engineer who never got successful, it is worth remembering that he did make a fortune (tens of millions in today's money) from his AC patents before he gave up on the royalties, but he died a pauper because he blew his fortune self-funding research into ideas that were much less good - too confident in his own promised results, he sunk all his money into ideas that just didn't work.
Try page margins, there's lots of room and they don't interfere as much with legibility.
Tried that, I had a great proof of this colonization concept, but this margin was too small to contain it...
Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet
For some, the ability to run their own code on a server with high bandwidth outward connection to the internet is all the power they need/want.
If the server is an authorised mail source for a domain (e.g. spf) then so much the better.
If the user has access to some writable disk space that can be used to host some interesting files, then there are uses for that.
If the user can read the web site source or config files that may have value in itself or may lead to further penetration - but I'm sure you've never seen DB user/pw in the source for a production website, ever ?
The easiest thing to do whether or not you can get a patched bash yet is to disable Apache's cgi-bin module.
and qmail procmail exim postfix sshd openVPN some inetds... and all the vectors that haven't been found yet.
The easiest thing to do is to fix bash - using rm if necessary
C. Like it or not, the bitcoins represent evidence. Seizing evidence is par for course in any criminal case.
Is selling the evidence off before the trial (which it was seized to be used in) also par for the course ?
What happens to seized evidence after a not-guilty verdict - or do certain people already know that is not a possibility ?
Nothing was stopping the angels either, per Genesis 6-4 "when the sons of God came in unto the daughters of men" and begat the Nephilim (or were the Nephilim depending on your translation). Enoch appears to make clear they are angels, but Enoch is apocryphal so you may or may not believe it enlightens the story in Genesis. It matters not though, because the story _is_ in Genesis which is canon, and whether the "sons of gods" (or Enoch's Watchers) are angels or aliens, they are clearly not-men but are capable of interbreeding with "daughters-of-men" and producing a race of giants (Nephilim).
As regards opening up a whole new mess, all of this is post-Eden and pre-flood, man can always complain to God: "you said I had dominion over everything so what are these more powerful beings doing taking all the good looking girls" , and God will say "yeah and ? Can I remind you that was back in Eden when I also told you not to eat the ****ing apples ?".
At least with Linux, if a security hole is found (and made public or released to experts in the security community or to the relavent developers or whatever), the number of people who are able to investigate and fix the hole (and make official or unofficial fixes available) is (in most cases) significantly larger than the number of people who would e able to deal with issues in Microsoft code. And the Linux guys can have patches out much faster (and they can get into distros fairly fast too)
There is a flip side to that, which is that too many cooks with no common management may royally spoil the broth, which is what has happened.
When found, this was embargoed and should have been fixed under embargo, properly. Instead, someone pushed out half-baked patches that were proved to be still vulnerable within hours (if not minutes), and by then everything was public. So now we have everyone and his dog patching in panic mode, three, four or more(?) sets of patches now, with each one still proving vulnerable, because collectively we blew our chance to fix it (and test it) properly the first time.
The eventual fix will have to be to stop playing who-finds-the-parser-bugs-first and accept that the whole feature is a security hole and needs to be removed or radically changed - something that could and should have been predicted at the start. There are various patches flying around now that do just that, probably in different incompatible ways. Those changes will, inevitably, break some stuff - and of course we could have looked and tried to figure out the extent of that, and mitigated the effect and been ready with the announcement, if it were still under embargo, but we blew that chance.
I am all for saying that the open source development model is better - but this really is not the best example to use to illustrate it, in fact it's already heading into embarrassing farce territory.
I can't imagine the stupidity of these security folks or programmers. bash is not remotely, remotely exploitable. Hint, there a program that listened to a network connection, then, it decided to try and pawn off security and trustworthiness to another program. That trust was misplaces and that program is wrong.
If you accept bash commands on a network connection and feed them to bash, then you are an idiot, full stop. Now, if you validate the arguments, the format and the content of the command, for example, you allow two formats true, false. Then, reasonably you can call bash to run those two commends. What you can't do is accept any arbitrary string and pass it to bash.
Problem is that in unix the way is for tools to call other tools, and the shell is so pervasive it could be anywhere. How do you actually _know_ if you are calling bash ?
* If you run /bin/sh are you calling bash ? Should you always check first ? Can you even check ?
* same for calling system() etc.
* If you run any other executable should you always check whether it is a script first ? Can you even check always ?
And this applies all the way down the pipeline, parts of which may be user/admin configurable.
Accept what you prove is trustworthy. Be willing to fix it, and claim responsibility when you are wrong.
No meta characters in environment variables, trivial, not meta characters in arguments, trivial. The argument should be a number, 0 to 255, check it _first_, then pass it.
Where in the pipeline ? What if you don't _know_ what the data is supposed to be at this point (only some other tool might do, down the pipeline, how then do you prove it is ok ? What does "no meta characters" mean in the context of an HTTP Cookie, or an email subject line ? - it is meaningless, arbitrary text is valid data in either case.
I thought we learned this with all the sql commands from the network bugs. We seemed to do the right thing for them, why do they have it so wrong this time around?
What we learnt was to properly sanitize and/or quote text that was executed as SQL commands. At the point that we knew it was going into a SQL command. Your web server doesn't know what you are going to use each form field for, "Robert'); DROP TABLE Students" is perfectly valid as a subject for a forum post, but as a user name in a SQL command it needs quoting first. The web server can't quote it, the cgi script or whatever down the line needs to quote it - if and when it gets used in SQL. Now, the web server also does not know and should not need to know what language a cgi script is in, but if it is bash, then bash will execute data as code before the script has chance to verify it.
This generalises to the whole pipeline - any caller may not know what the data it is passing down the pipeline in the environment (or otherwise) actually _means_, or what is valid/non-valid/malicious. Such determination can only be made by the callee that understands the data - but bash may execute it before it gets there.
Let's assume you are right and we can compare with SQL Injection. With SQL Injection we learned we had to properly quote data before feeding it into SQL, and fix all the places we do that. So, with bash injection, now that we know about it, to do the same we would need to sanitize / quote all environment variables whenever we call bash. Except we don't know when that is (see above), so you really mean that every program that execs any other program or feeds into any other program in a pipeline where that program might possibly be a shell script, needs to quote environment variables. That is just about every unix program ever written (and, er, where/when are you going to unquote that data ?).
Or we fix bash, the program that is actually blindly executing data as code.
maybe, "How many hackers does it take to change a light bulb ?"
Would be better if you stopped waiting and started checking.
10secs on google finds lists of shellshock attack vectors including:
qmail, procmail, exim, some inetds, ssh, openvpn, dhclient
That is just some of the ones the good guys have found and advertised so far...
Worth listening to sales, sometimes there is value in what they say, and you need them on side - it isn't fun (or good for job security) writing great software that they can't or won't sell. The suggestion is good as far as it goes but I would say it isn't as simple as that.
Unless you are open source, your dev teams bug trackers should be their area and confidential to them, they may not all be commercially aware customer facing people, they may speak their mind in choice terms about some bug reports, and you shouldn't have to be constantly afraid of that turning up in front of the customer. It isn't just dirty laundry, it's the whole cleaning process and every dirty comment you make whilst doing it.
Then, each customer has their own issues which should be confidential to that customer (and you). Some issues may not be bugs but embarrassing customer mistakes, and customers _will_ (sooner or later) put information into an issue that is commercially confidential, personal information (data protection) or security related. Sometimes this is necessary - bugs may only be tripped by certain data, and it isn't the customers job to determine the general case, it's your job when investigating. Support and dev need to understand that issues are private to a customer, but also sales so they can explain it positively to prospects: "can we look at your issue list ?" "we can't show you customer reported issues because we treat them as confidential to that customer - we believe customers should be able to report exactly what happens which may include their data, rsther than be required to create a general test case". Customer issue lists are not a concern of sales but rather account management - the customer account manager may be in sales, but if so it is a different role they are doing.
Then you (maybe) have general issue list(s) that are visible to all customers - effectively a dynamic tracking view of what will be in the release notes (see below). You need to re-create issues here from the customer reports - not just blindly copy customer report - and really these should be general cases not just what the customer reports. E.g. customer reports issue with Web UI display of account named "P&O", you establish it's an issue with ampersand, and what you report to all customers is that there is an issue with ampersand, otherwise you risk reporting too narrow a bug and exposing customer confidential information. Not every issue will make it to this list, only if it is of general concern, and issue that affects a configuration only used by two customers who have already been informed has no relevance here. I still see little value in this list being public beyond customers, but it should be expected that it might become public at some point (possibly via a customer) and information in it should be written accordingly, at very least it is available to all customers. For these reasons sales may sometimes be involved in decisions as to what goes on this list.
For betas and dev builds etc., maintain separate lists and give access only to those customers who are running those versions, make them feel special, but also your SLAs etc. will be different for non-production versions and this helps keep that clear.
Finally, release notes - fixed issues and known outstanding issues. If you provide public downloadable demos, or you provide demo installs to sales prospects, then these need to come with release notes, so these documents go (at least) beyond your customers. For that reason you don't just dump (any of) the lists above into the release notes, each issue needs to be vetted for inclusion (see above for relevance, plus you want to inform not overwhelm) and rewritten to show your customer service in a positive light - this is effectively part of your shop window.
I would recommend trying to get sales (and maybe marketing) involved in reviewing (and editing) release notes, they are technical documents that need to be customer relevant and readable, sensitive to commercial needs and priorities, and hen
Check your distro. Believe RedHat at least have newer allegedly more complete patches - although there are also posts saying you'll need a support contract for some older versions of RedHat.
My guess is that initially this was embargoed while GNU/FSF guys "fixed" it, but when we find out fact that the fix was no good everything is already public so now everyone downstream is trying to fix it themselves as fast as possible - RedHat etc. may do their own without waiting for upstream. It's now that you find out how good your support is, from whoever you paid for it or from the guys who work for free if you paid no one.
If you want the diy approach, personally I would look at the initial patch for where the offending code is and rip out the entire "feature", I suspect very few scripts will break.
Alternatively, patch bash using rm.
I think the bigger than heartbleed comments might be a bit overblown. If you're running CGI and your web server is running as root, you probably have a serious problem. Otherwise, it's just a PITA when you have other things to work on. Can anyone tell me why the script kiddies are scanning 23? I haven't seen an open telnet port in years. From all the reports I've read, about the only things vulnerable are web servers running CGI which was pretty vulnerable before.
ssh is also vulnerable (often configured to pass TERM and maybe LC_*)
Git repos using locked-down ssh - vulnerable
dhclient - vulnerable
CUPS - vulnerable
Those are just the ones we know so far.
It is different to heartbleed, and it could indeed get bigger. Heartbleed required zero effort to get the data but then needed some luck and some work to find keys or login info within it. Manual work required before you could break into a system.
ShellShocked on the other hand is direct, trivial, remote code execution. Attacks can easily be fully automated - it is wormable, trivially. The question now is not whether or not fully automated worm attacks will happen or when - they already are - it is how many servers they will get.
And that is all before we start looking at all the embedded Linux out there that may have bash, and often have cgi. It may take longer to find exploit vectors for those, but it will also take longer to patch, and some may not be patchable. Add in to the mix that small business / home routers often also run dhcp servers, and that dhclient is vulnerable, and a router compromise can open up any unpatched client machines inside the firewall.
No one knows how big this _will_ get, but it _could_ be bigger then HeartBleed, easily.
So... unless your CGI script is extracting a header field and feeding it to a bash script... you should be okay in terms of HTTP requests with this in their header?
Keep your head in the sand, it's less scary that way.
Or realise that your CGI server feeds headers to your CGI processes in environment variables, because that is how CGI is supposed to work, and that it isn't just your CGI script it is every single process it starts (all children and descendants) that must not be a shell script and must not use system() etc. Perhaps then also note that CGI is just one vector that happens to be being attacked right now and there will be others, some we probably don't know about yet.
Or you could assume you are vulnerable and patch bash, or remove it.
Your web server might be responding with a 200 response code, but that's just because whatever the URL requested is, is being successfully sent.
Thoughts?
Correct - no need for attacks to cause any error at all. May be possible using an http header you aren't logging at all, giving you no way to detect it.
However, this has nothing to do with users on your box maybe trying to do privilege escalation with this bash trick. But... this isn't a privilege escalation trick - the user shouldn't have any more access to the system than he would have with running the commands directly, right?
Find a setuid script or setuid program that somewhere uses the shell and it's a privilege escalation too. Such things _should_ be very rare by now, but not impossible that some still exist.
1. the first fixes, within 24 hours of announcement, didn't actually fix it fully - in fact I suspect it will still be exploitable in some way or other until the "feature" of treating environment variables as code is removed completely
2. providing an incomplete fix may be worse than taking a bit longer to properly QA the fix - a lot of admins may believe they have patched this based on the first announced vulnerability tests and the first set of patches, but in fact they are still vulnerable with a trivial change in the malicious bash code
3. it was less than 24 hours after first being made public - this may be entirely unrelated to when it was first found
We have no idea who found it first or for how long it may have been used covertly (did NSA etc. know of heartbleed before public knowledge ?)
We don't know what prompted someone to be looking for problems in code that hasn't changed for 20+ yrs.
It is so trivial to get remote code run with this bug (no unexpected new process or login or errors) that I doubt it will trip any intrusion detection systems.
If you can use an http header that isn't logged, then you could run code on the server and extract information and it may be completely undetectable.
Something else we don't know is how the FBI really got the Silk Road server to cough its real IP address. The FBI claim they put "miscellaneous characters" into the login form and it just happened to send the address back. You can believe that if you want. It may or may not be related (I have no idea about the silk road server setup), but a handful of days after the FBI put their story out someone is looking for security holes / bugs in very old bash code. Maybe there was no trigger and they just happened to get bored one day and decide that looking for bugs in bash would be fun. Or maybe there is more behind this than we know.