IT All Falls Down

For how long has the world’s IT been running naked, with anyone on the network able to take over the whole system?“it’s high impact and easy to exploit. And if you are exploited, the price is high, irrespective of any damage the attacker does: The only way to remediate is to rebuild the domain from scratch. Don’t let this happen to you.” Any length of time is too long. Yesterday, M$ told the world they were naked and now system administrators are scurrying around to make sure every system running InActive Directory has a patch. Meanwhile, the bad guys have been out there a while compromising whatever they could phish into.

Monoculture is dangerous whether it affects the survival of you progeny, your supply of food or your IT. Don’t let it happen to you. Use Debian GNU/Linux widely to avoid monoculture in IT.

This makes the occasional flaw in GNU/Linux pale into insignificance. What will M$’s apologists write now? That M$ has the One True Way to do IT? That the problem is fixed? That it’s the user’s fault??? Ignore them and think for yourself. M$ has let down the world in a big way. Would you continue to do business with the locksmith who installed a useless lock on your front door? Would you continue to do business with the car-maker who cranked out ten million lemons even after discovering the problem? Would you permit your daughter to date a guy with a history of vehicular crashes? Would you do business with a company that can’t rely on its own software? Don’t do it. Get software that works for you, not M$, M$’s “partners” and the bad guys. Get Debian GNU/Linux.

See Details emerge on Windows Kerberos vulnerability.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , , , , . Bookmark the permalink.

19 Responses to IT All Falls Down

  1. oiaohm says:

    DrLoser
    I was the one to point out the “function as environment variable” issue here, oiaohm. I don’t claim originality. It was common knowledge. Which you ignored, didn’t you?
    No you did not show the your cite and read it. Yours said a fork was required in fact its not. The means to define a function as environment variable is the problem.

    If the follow line works
    bash -c shellshocker='() { echo You are vulnerable; }’;shellshocker
    You have CVE-2014-6278. Notice a lot of the test cases for CVE-2014-6278 incorrectly include bash -c in the middle of line because people were thinking fork was required.

    DrLoser you said a fork was required this is not the case. A environmental variable should not be a function is also not exactly true. But do a set on current day Linux distributions and you will find a lot more shellshock class exploits waiting.

    DrLoser you said “temporary environment variable” No allowing any environmental var containing a function is the security flaw. Attackers could use non temporary forms of environmental vars to rootkit DrLoser. Reason why you have to say any environmental var there is in fact a type function environmental var.

    Even current day Linux shells have a hell lot of type function environmental var. Shellshock is blocked for now. If an exploit exists to allow e type function environmental var to be messed with it will be back.

    Reason why you have to say any environmental var there is in fact a type function environmental var.

    https://capec.mitre.org/data/definitions/13.html a function in an environmental var results in abuse of normal flow. Prevention of capec-13 means you should filter all environmental variables. Shellshock attacks of placing a function in a environmental var also fails remotely if processes against capec-13 are done. All remote provide environmental var filtered.

    To prevent a possible flaw with type function environmental var as well capec-13 prevent stuff needs to be implemented.

    DrLoser Shellshock comes from something. It comes from 1) alias command as define and then correct in the posix standard as of 2008 2) Posix first First define of how shell script functions. Both say define as envornmetal vars.

    bash -c shellshocker='() { echo You are vulnerable; }’;shellshocker
    This line working is valid POSIX.1 prior to year 2000. This line is invalid in Posix.1 2000 and later should fail. Please remember Windows services for unix is not certified for Posix.1 2000 or latter so there might be a shellshock bug in there.

    Shellshock is also a example why a little bit more due care has to be taken when writing standards.

    Reason why there was need for so much advertisement over shellshock is the fact other shells out there could be implemented by old posix standards and be lethal.

    Yes the out of date nature of Microsoft Posix support is a worry.

  2. DrLoser says:

    Normal people would accept that ShellShock has no obvious relationship to the CVE categorisation of vulnerabilities via environment variables.

    Normal people would accept that this is, in fact, an awkward little bug inherent in the design of Bash, which is that (as I said) it is effectively a REPL. Although a particularly inept one, with a sad lack of security.

    Fortunately for those of us who enjoy a chuckle on a dull Sunday evening, oiaohm is not normal:

    Function in environmental var was the big security flaw of shellshock. The other bits were just icing on the cake.

    1) I was the one to point out the “function as environment variable” issue here, oiaohm. I don’t claim originality. It was common knowledge. Which you ignored, didn’t you?
    2) Anybody who refuses to recognise the subsequent, theoretically unbounded, execution of a function via an environment variable is …

    … not obviously trustworthy when it comes to issues of security.

    Icing on the cake indeed.

  3. oiaohm says:

    Yes 1 coding error causes 6 CVE numbers. Shockshcoker attack cannot work with just CVE-2014-6278 patched. Function in environmental var was the big security flaw of shellshock. The other bits were just icing on the cake.

  4. oiaohm says:

    https://shellshocker.net/

    DrLoser shellshock is not one CVE. This is the example of them.
    Notice the issue is with functions defined in environmental vars.

    The most common used Shellshock CVE is CVE-2014-6278.

    Sorry DrLoser you don’t know Shellshock bug at all. Yes its 7 exploits 6 with CVE numbers.

  5. DrLoser says:

    That is not how the Shellshock attacks mostly worked. Most them were working on the fact that a environment var overrode bash functions. So http server due to client direction sets environment var when php call shell hello exploit.

    PHP call shell hello exploit???

    Try again, oiaohm.

    Now, I want to be fair here. You will notice that I do not provide a cite to demolish oiaohm’s ludicrous fantasies.

    Clearly, oiaohm and I differ, quite substantially, on how ShellShock — whoops, despite myself, I just included a cite — works. So here’s a few easy questions for everybody to answer:

    1) Does it involve a pre-existing environment variable?
    2) Did Bash through v4.3 allow a “run-on” call to a freshly-minted function?
    3) Given that the exploit actually makes Bash sound like a “proper” interpreter, ie you can’t have a run-on (2) without a REPL, is there actually some very bleeding obvious security hole involved in running a CGI script with a REPL behind it?
    4) And so on.

    There are intelligent people out there on this site who understand and are qualified to comment on these things.

    oiaohm is evidently not one of them.

  6. DrLoser says:

    This is an exploit that never got in the wild and came out of starting formal auditing.

    Still missing a cite, I see. Mommy will be very displeased with you, oiaohm. I sense a spanking coming up.

    Look, this works one of two ways:
    a) It was a real exploit (and it isn’t even necessary to prove that it was “out in the wild”). In which case Brian Gorenc et al are culpable for not telling people to get it fixed.
    b) It never got out “in the wild,” to use your formulation, oiaohm. In which case, what’s the fuss? Although it would be nice to think that Brian Gorenc had written a memo to somebody in Microsoft. Which, absent any cite, we have to presume that he did not.

    Either way, FLOSS doesn’t come out of this smelling of roses.

  7. DrLoser says:

    What DrLoser is describing here is how to test a shell to see if it has a Shellshock flaw.

    The problem the test for a flaw and usage of flaw are two completely different things.

    No, oiaohm, what I am describing (with a cite, I might add) is the difference between your random CVE link (regarding the manipulation of an existing environment variable) and ShellShock, which actually invents an environment variable out of thin air … and then further uses an inherent weakness of the Bash shell to utilise that security hole.

    I’m beginning to think, oiaohm, that you have never actually used the Bash shell. Clearly, you don’t understand the consequences of ShellShock.

    And as for this “testing vs usage” thing … Preposterous.

    “I’m not going to use this flaw that is clearly shown up via testing. That would be ungentlemanly. I think I’ll go away and dream up another way of usingit.”

    You have no idea how extremely ignorant and silly that makes you sound, do you, oiaohm?

  8. ram says:

    It should always be remembered OpenSSL was, and is not, the only SSL for Linux.

  9. oiaohm says:

    Basically, ShellShock introduces a temporary environment variable into the current shell, induces that shell to fork (and inherit the temporary), and then executes the function defined by that temporary.
    What DrLoser is describing here is how to test a shell to see if it has a Shellshock flaw.

    The problem the test for a flaw and usage of flaw are two completely different things. The usage of ShellShock follows CAPEC-13. Prevention methods against CAPEC-13 would have stopped a lot of Shellshock attacks dead in tracks.

  10. oiaohm says:

    DrLoser
    So, your “bad news” is that a FLOSS project detected a severity 9.0 CVE issue five years ago and somehow failed to tell anybody about it?
    The told Microsoft. And if I bother diggering back in the windows CVE numbers from 5 years ago it is there.

  11. oiaohm says:

    DrLoser you are idiot.
    https://capec.mitre.org/data/definitions/13.html
    That is exactly what Shellshock is.
    According to the technical details, a hacker could exploit this bash bug to execute shell commands remotely on a target machine using specifically crafted variables.
    This one line in your own quote. If you cannot set environmental vars with what ever names you like you cannot exploit bash this way.

    Subverting Environment Variable Values is require to perform a Shellshock attack. Just happened that bash processes those Environment Variable Values in some horribly bad ways. Could there be php script or python or perl …. scripts out there with same issues hell yes. The damage shellshock causes could have happened with any other environmental var exploit. Not enough is done to prevent this class of exploit.

    On the samba bug did you even bother reading the credits DrLoser.

    This vulnerability and proof of concept code was provided by Brian
    Gorenc as well as an anonymous researcher working with HP’s Zero Day
    Initiative program. The Samba Team would like to thank them for
    reporting the problem and their cooperation in this matter.

    This is an exploit that never got in the wild and came out of starting formal auditing.

    You may believe that Andrew Tridgell and the rest are dangerously delinquent members of the community, oiaohm, but I choose to believe differently.
    DrLoser I don’t believe Andrew Tridgell and the rest of his group is perfect. This is why Audit teams exist.

    Not doing enough auditing has been a very big problem. The HP’s Zero Day
    Initiative program is the one that found the issue I was talking about.

    DrLoser remember for years Microsoft refereed to take part in protocol validation programs. Required a ruling by the EU so they would attend.

    Basically, ShellShock introduces a temporary environment variable into the current shell, induces that shell to fork (and inherit the temporary), and then executes the function defined by that temporary.
    That is not how the Shellshock attacks mostly worked.
    Most them were working on the fact that a environment var overrode bash functions. So http server due to client direction sets environment var when php call shell hello exploit. Shellshocks realworld usage is a pure type CAPEC-13. Lack of mitigation against CAPEC-13 is why most of the Shellshock attacks worked.

    That it worked how many more CAPEC-13 attacks are out there. This is what we should be worried about.

  12. DrLoser says:

    Then again, I’m sure Tridgell & Co know what they’re doing. (This particular tidbit provided to forestall the WallOfGibberish that will no doubt arrive soon from the wilds of northern NSW concerning how M$ have Had Their Evil Way with the SaMBa project.)

    Versions of Samba 3.6.3 and lower suffer serious security issues which can allow anonymous users to gain root access to a system from an anonymous connection, through the exploitation of an error in Samba’s remote procedure call…

    … it says here on a straightforward Wikipedia page that even oiaohm must have stumbled across some time in the last few years, what with SaMBa being one of his big Pack Rat Linky themes.

    Oh, dear. Well, obviously, Wikipedia must be mistaken. (They should have asked Robert for a Peer Review.)

    Nope: apparently not.

    Perhaps this is some form of bizarre and dangerous “one-upmanship” by the SaMBa crew? Apparently this fits in with oiaohm’s limited understanding. “We found a massive hole in your security, five years ago, M$! Take this! We can be equally clueless, if not more so!

    Or perhaps it’s just an everyday tale of FLOSS folk who leave root access dangling for eight years (assuming it’s only 3.x that was affected) or possibly double that (assuming the happily unlikely circumstance in the Alternate Universe of Linux that “backward compatibility” was a concern).

    Place Bet Now! Banzai!

  13. DrLoser says:

    DrLoser and Deaf Spy I have some bad news for you. Samba project detected this fault 5 years ago.

    So, your “bad news” is that a FLOSS project detected a severity 9.0 CVE issue five years ago and somehow failed to tell anybody about it?

    You may believe that Andrew Tridgell and the rest are dangerously delinquent members of the community, oiaohm, but I choose to believe differently.

    I see them as nothing more than simple-minded idealistic buffoons with a very obviously limited ability to implement a standard protocol. I’m absolutely certain that they would have shouted this defect to the rooftops, had they found it.

    Which leads me to suspect that, once again, oiaohm, you are making up your claims out of thin air.

  14. DrLoser says:

    The reason why I see Shellshock as yawn is this. https://capec.mitre.org/data/definitions/13.html.

    And the chances of you ever being hired as a “security expert,” even for the likes of Mrs Miggin’s Pie Shop, recede ever further into the distance, don’t they, oiaohm?

    Typical Severity: Very high. “Yawn,” says oiaohm.
    Typical Likelihood of Exploit: Very high. “Yawn,” says oiaohm.

    ShellShock is a very different beast indeed, oiaohm, as anybody with a modicum of IT knowledge would recognise very fast. But before I go on to explain why it’s very different, let’s have a bit of fun with the lesser desiderata.

    Exploiting environmental vars to breach security has been going on for years.

    Yes, it’s a wonder the Internet is still standing on that assumption. Which leads one to infer that that assumption, in all likelihood, is bogus. Now, what might lead a boffo IT wizard like oiaohm to such a bogus conclusion? Here’s a clue:

    Yet for some reasons http servers have allowed clients to set what ever environmental they like.

    1) No they have not.
    2) You’ve completely misread your cite, as usual, oiaohm.
    3) The main problem with environment variables, in this instance, is that an attacker who has already breached the relevant security wall can manipulate them and cause unintended behaviour in an HTTP server.
    4) This can (and should) be mitigated by standard security behaviour, ie “principle of least privilege.”
    5) An attacker can doink around with Cookies and with bits of the URL in order to figure out details of one or more environment variables. Quite frankly I would regard this as a whole lot of effort when there are juicier fruit around, like outward-facing FTP servers. But whatever. It might gain you valuable information, particularly if you have access to the source code. Rah Rah FLOSS!

    Anyhow, none of that is relevant to ShellShock, because, you see, ShellShock doesn’t manipulate any environment variables at all. It does manipulate the concept of environment variables, which is a wholly different thing and, as far as I know, unique to the Bash shell.

    (It might also be a “sublime feature” of other *nix shells. But most of the rest aren’t anywhere near as bloated as the Bash shell, so I doubt it.)

    Basically, ShellShock introduces a temporary environment variable into the current shell, induces that shell to fork (and inherit the temporary), and then executes the function defined by that temporary.

    All very clever, but only tangentially related to “environment variables.” As oiaohm would know, if he actually knew anything at all about how Linux works.

  15. kurkosdr says:

    “Would you continue to do business with the car-maker who cranked out ten million lemons even after discovering the problem? ”

    You are essentially describing GM, the world’s largest automaker.

  16. oiaohm says:

    Deaf Spy HeartBleed is Openssl issue.
    https://www.openssl.org/news/vulnerabilities.html
    The list of faults every year for openssl has been insane. Please note these are all only mainline code bugs not third party patch caused bugs.

    Deaf Spy also read that boringssl link carefully.
    BoringSSL incorporates the patches the Chocolate Factory has been adding to the OpenSSL code for its own use
    Chocolate Factory is code words for Google Internal. Everyone has been forking OpenSSL with custom patches because they have not trusted the upstream maintainer. Result is everyone has been running under validated SSL.

    OpenSSL is basically a case of a unwillingness to fork.

    ShellShock is gone for good. But the worry is any other errors that can be caused by environmental var setting. Please note issues in the past had happened with IIS with http setting environmental var and bad things happening.

    Why the Linux world reacted so much to both “HeartBleed and ShellShock” is both of them are only possible due to weaknesses that have allowed other flaws in the past.

    Deaf Spy debian can use yassl instead of openssl. Where possible debian has two of everything. So avoiding most mono culture problems. Not 100 percent there are areas where Debian lack duplication.

    The reason why I see Shellshock as yawn is this.
    https://capec.mitre.org/data/definitions/13.html
    Exploiting environmental vars to breach security has been going on for years. Yet for some reasons http servers have allowed clients to set what ever environmental they like. Note IIS is also gulity of this.

    OpenSSL issues there is something to talk about and it mostly not Hartbleed focused.

  17. oiaohm says:

    DrLoser and Deaf Spy I have some bad news for you. Samba project detected this fault 5 years ago. When trying to work out how come Windows Servers were so fast at auth compared to Linux ones. Yes Windows servers and clients were not looking up the main directory to check if Kerberos information was telling truth.

    Desktop Windows is not vulnerable, but they issued the update for desktop systems anyway. The code is in the desktops, it may as well be correct.
    Lier Lier pants on fire. Kerberos information is used by Windows Clients to tell if user domain administrator and if user is domain administrator you are allowed to alter the client computers registry. This breaches client and servers.

    Why does it not breach samba installed systems. Samba use Kerberos as per defined rules. Basically don’t trust the sod.

    Samba found this same bug 5 years ago when they were able do the follow
    1 auth against KDC
    2 delete user.
    3 login to server and clients using the delete KDC provided information.
    Yes they fixed this by adding a check to make sure user was not deleted. Yep lets just check account name lets not bother checking the security information.

    There is mostly likely a few more issues.

  18. DrLoser says:

    For how long has the world’s IT been running naked, with anyone on the network able to take over the whole system? Any length of time is too long.

    Indeed it is, Robert. But I can answer your question quite easily: the world’s IT has been doing no such thing.

    I encourage you to look into the bug in question. You’ll find that, although it is certainly “critical” in security terms, it has certain characteristics that severely constrain quite how “critical” it is in operational terms.

    OpenSSL, HeartBleed and ShellShock, not to mention the insanity of leaving an outward-facing FTP port open, have no such characteristics.

    But hey, nice headline. Shame about the reading comprehension.

  19. Deaf Spy says:

    How exactly is Debian not a mono-culture?

    P.S. You are quick to forget OpenSSL, HeartBleed and ShellShock. Pogson. OpenSSL is still not completely patched up, and even Google can’t fix their Chrome browser not to use it.
    http://www.theregister.co.uk/Print/2014/07/25/chrome_boringssl_switch/

    Say, how come that? MS at least already have a patch. Where are the patches for this trinity of Freelandia?

Leave a Reply