Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug Open Source Security Linux

Magnitude of glibc Vulnerability Coming To Light (threatpost.com) 139

Posted by timothy from the low-level-errors dept.
msm1267 writes: The glibc vulnerability disclosed this week has some experts on edge because of how DNS can leveraged in exploits. Dan Kaminsky said that while man-in-the-middle attacks are one vector, it would appear that it's also possible to exploit the bug and attack most Linux servers via DNS caching-only servers. 'This would be substantially worse if it went through the caching ecosystem; 99 percent of attack vectors go through that system,' Kaminsky said. Glibc, or the GNU C library, is used by most flavors of Linux and also a number of popular web services and frameworks, giving attacks potentially massive horizontal scale. The major Linux distros have patched and pushed updates to servers; source code is also available for homegrown Linux builds.
This discussion has been archived. No new comments can be posted.

Magnitude of glibc Vulnerability Coming To Light More

Magnitude of glibc Vulnerability Coming To Light

Comments Filter:

  • That's what they get (Score:5, Funny)

    by Anonymous Coward on Thursday February 18, 2016 @10:19AM (#51534617)

    For being glib about it. (ba dump)

    • Re: (Score:2, Funny)

      by Anonymous Coward

      I c what you did there.

    • I was just getting exited over a vacation to the glib sea, but then I saw on the news that it is being invaded by pirate hackers, and everybody says they're really vulnerable so I guess that means nobody has confidence in the local security.

      I think I'm going to change my plans and just stay with the hurd until the danger passes.

  • CVSS score was medium of 6.1 (Score:1)

    by Anonymous Coward

    The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed since it requires more environmental factors to be a successful exploit.

    Most likely organizations have much worse and easier exploitable vulnerabilities than this.

    • The CVSS score is a medium of 6.1 for the CVE. So this isn't as bad as Heartbleed

      First, Heartbleed was actually a 5.0 base score, so this is more serious if you go strictly by CVSS score (which is not necessarily advisable). Reference [nist.gov].

      Second, CVSS scores are based on a certain formula and small set of conditions; in particular, vulnerabilities are scored based on their immediate impact and not necessarily things that occur down the line. In other words, CVSS base scores do not include environmental metrics (There is a CVSS environmental score, but almost no one uses it except for CERT).

    • CVSS does not take into account how widespread a defect is. A defect with a low CVSS score that happens on just about every machine in the world is in some ways worse than a high CVSS defect that is only deployed on a handful of machines.
  • Comment removed based on user account deletion

    • Re: (Score:1)

      by Anonymous Coward
      Unfortunately, the slashdot IP address changed dice kicked us to the curb and APK can no longer connect. If only there was some sort of distributed hosts file that automatically updated when IP addresses changed...

    • Re: (Score:1)

      by Anonymous Coward

      I still see APK posting here and there, mostly harassing whipslash, which is a fool's errand. But he's not able to spam every discussion thread with 20 posts full of bold italic psycho=>babble anymore, and I call that a victory. I'm rather enjoying the new /. ownership so far.

  • Still on DVL (https://en.wikipedia.org/wiki/Damn_Vulnerable_Linux), so I must be secure from this...

  • A patch to a .so file is a great fix for most things... But, if you build your own statically linked executables please "make clean", "make"

    Just a friendly public service reminder from the "Grey, but still alive"

  • Defense (Score:2, Interesting)

    by Anonymous Coward

    iptables -t raw -A PREROUTING -p udp --sport 53 -m length --length 28:2000 -j DROP
    The above line will block any attack based on this vulnerability.
    It may impact some unusual but legitimate queries, though. Normal DNS queries usually have small enough responses to fit in this range.
    If the above line is on a Linux machine that is performing as a trusted caching DNS server, it will also protect the clients from the attack.
    You might be able to get a few more bytes into the threshold (because there are headers i

    • Re: (Score:2)

      by Skiron ( 735617 )
      Also add:

      edns-packet-max=512

      to your dnsmasq.conf if you run a local caching DNS server.

    • Re: (Score:2)

      by cnettel ( 836611 )
      The bug can hit you with DNS over TCP as well. While that is somewhat of an oddity, I am not yet confident to say that you can rule it out, especially if you have a MITM that might be able to trigger fallbacks. Since the TCP response could be fragmented over several packets, things rapidly grow beyond iptables capabilities there. (But the "TCP DNS response fragmented over several packets" would thankfully not propagate through layers of caching internal DNS servers.)

  • strlcpy() isn't good enough for glibc. (Score:5, Interesting)

    by emil ( 695 ) on Thursday February 18, 2016 @11:03AM (#51534835)

    No, it "only leads to other errors" [lwn.net].

    Funny, I haven't heard of any showstopper bugs in OpenBSD libc - not this year, not ever. And it's ubiquitous, since I'm running it on my phone [undeadly.org].

    This bug, after ghost, would be a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.

    • a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.

      What to remove?

      Features. New features. Old features are fine, they can receive bugfixes only. Refactoring may be done once every 10 years, but only if the code appears sloppy.

      Done.

      Even Matt's Script Archive became secure over time. Sucky code can be slowly improved until it borders perfection, but only if it still does the same thing it used to do, and no more.

  • Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307 [launchpad.net]. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.

    Good luck exploiting this bug.

    • This sort of sounds like the bravado of someone who is sure that they are protected because they have anti-virus software installed.

      • Re:Minimal impact (Score:4, Insightful)

        by bluefoxlucid ( 723572 ) on Thursday February 18, 2016 @12:30PM (#51535593) Homepage Journal

        Anti-virus software is an arms race. This is a change to the fundamental behavior of the compiler toolchain and produced code.

        Think like someone tells you dishwashers are dangerous because they use high-temperature hot water, and then your glasses all crack because they drop from 145F as they're exposed to the cold air when you open the door after a wash cycle. You then point out that your glassware is all borosilicate glass and can take a temperature drop of 120 degrees celsius across 1 second without damage. Going from boiling to ice water won't break your glass; heating it dry over an acetyloxy torch and then dumping it in an ice bath *will* shatter it.

        What you're looking at here isn't a system that catches one specific attack signature. You're looking at an attack which fundamentally relies on overflowing a buffer on the stack, rewriting RETP with an address on the stack that contains code injected as part of the overflow, and then jumping into that code on RETL instruction. This executes your code from the stack.

        Meanwhile, the software being attacked stores a runtime-randomized word between the stack variables and RETP, then verifies it hasn't changed before a call to RETL, so you have to guess a 32-bit or 64-bit integer (1 in 4 billion or 1 in 16 billion*billion). If that fails, the system *still* has randomized the stack base, so you have to load a value into RETP which points to your code on the stack, which can be in any of thousands or millions of locations. Should you manage to guess both a one-in-four-billion and a one-in-524-thousand value simultaneously (one-in-2251-billion-billion) (or bigger on 64-bit), the stack is still non-executable: the OS will claim a general protection fault due to trying to execute non-executable memory.

        That means this attack can't be carried out successfully without extreme luck (1 in 9.7 billion billion billion) or advanced knowledge of the program's address space (which the attacker must inspect while the program is running--it changes on every run); and even then, the attack has to do something distinctly other than injecting code. Heap, main executable, and library load addresses are also randomized on each run, so luck in dodging out the primary protections leads directly to rolling bigger dice in hopes of getting lucky a third time.

        In this particular attack, you can't just launch an attack at a target. You have to gain control of DNS responses for that target, then wait for the target to make a DNS query. All of the above then apply. Good luck.

        • While you are probably correct. It still strikes me as hubris to be so dismissive.

          Also, you know a lot about dishwashers.

          • You comment about dishwashers using hot water, but not about glass that can handle sudden temperature differentials?

            I'm being realistic. It's like saying you can't do any banking on the Internet because someone could steal your credit cards when you log into your bank site; that worked in 1990, but we've since started using SSL and 128-bit encryption. Banking is safe, and running around screaming that the packets go through a bunch of routers in between and someone might be able to read the data is just

            • Most nerds think about the properties of different types of glass with some frequency, because glass is a common material that we interact with in multiple areas of life.

              We also hear a lot of idiots say a lot of idiot things, generally consistent with the scene you described. However, I've never heard that one about dishwashers being dangerous. It is hilarious. Absolutely more surprising than knowing about glass properties.

              Also, here in the US a "high temp" commercial dishwasher is expected to reach 180F on

              • Dishwashers aren't dangerous per se. It's just that cheap soda lime glass does crack when heated. I've had glass mugs explode in my hand while hand-washing: when pulled out from under the faucet, the cool air caused the glass to contract and crack, sometimes loudly, sometimes energetically. I lost *six* mugs in a set that way, the type made of green-tinted glass that's not thermally stable at all. If you open a dishwasher while the same type of glass is still hot, you expose heated glass to cool air;

                • ... I've had glass mugs explode in my hand while hand-washing: when pulled out from under the faucet, the cool air caused the glass to contract and crack, sometimes loudly, sometimes energetically. I lost *six* mugs in a set that way...

                  Wow, that exposes your debugging skills pretty bad. One, OK. Everybody makes mistakes, one bug is not even a foul. Two, well, your first theory was just that it was a flawed unit. Three, OK, your first mitigation technique didn't work. Six? And then you're going to go on from there to lecture on code quality? You focus a lot on temperatures, I can inform you right now that your hot water heater is not adjusted to specification, and you failed to expect to need to adjust your washing technique to mitigate th

                  • I simply assumed the glasses were shit, and stopped using that type of glass after they all broke. It's the same principle behind never [youtube.com] using perl [youtube.com].

                    I can inform you right now that your hot water heater is not adjusted to specification, and you failed to expect to need to adjust your washing technique to mitigate that.

                    You seem to have not noticed it didn't burn my hands.

                    the nuclear containment building is not a viable metaphor for the type of code mitigation strategies you describe.

                    It limits the scope of damage without preventing the actual precipitating event. C buffer overflows no longer allow remote code execution, but rather cause denial of service. With privilege separation strategies, you use a non-privileged daemon to sendmsg() a file handle (e.g. TCP connection) to a privile

                    • I simply assumed the glasses were shit, and stopped using that type of glass after they all broke. It's the same principle behind never [youtube.com] using perl [youtube.com].

                      Didn't read past that. That wouldn't get you to six, it would get you to one or two and then you'd throw away the rest. There would be no reason to wash the remaining one using the same technique that was proven flawed for that unit; deciding the units were all crap would underscore that, not eliminate it.

                      BTW, welcome to slashdot. No, we don't click video links. This is a place for stuff that matters, not stuff too vapid to write down.

                    • Why would I simply throw away glasses I could get a few more uses out of? I drive a 2004 Mazda 3; should I get a new car because third gear's been broken for 2 years?

                      The shit you've been babbling about is more vapid than anything on YouTube.

    • It can [phrack.org] be [coresecurity.com] done [corelan.be]. In practical terms, it means you need to find more than one bug to exploit it and get around the protections.

      • Yes, it requires even-more-unlikely scenarios.

        Among those, many of the techniques you've provided require the ability to write to arbitrary memory locations (in which case you can use *that* bug to emulate *this* bug, so no change). Some rely on Windows Safe Exception Handling exploits. One of the methods given is "attack a function that isn't protected", which is a handwave.

        The phrack article has a program exploiting itself by inspecting its own memory space and then jumping over terminator canaries.

    • Re: (Score:2)

      by cnettel ( 836611 )

      Has to get around stack overflow protection canaries (-fstack-protector-strong or -all), address space randomization, and a non-executable stack and heap. Ubuntu has run -fstack-protector-strong (covers functions calling alloca()) since gcc 4.9 release after 2015-05, according to #1317307 [launchpad.net]. Kees Cook added the -strong feature to gcc, and is part of Ubuntu's compiler team, so it went straight into Ubuntu.

      Good luck exploiting this bug.

      Denial of service by crashing the process is of course not as nasty as remote code execution, but it can easily be nasty enough, especially if the properties of DNS would allow you to penetrate deep inside networks and services generally believed to be protected. My personal favorite vector here would be XML exposed to parsers that auto-load whatever DTD or other schema that is specified.

      • This is all true; and yet the media machine dismisses all denial-of-service attacks, all bugs that just crash your application, and instead jump up and down with white sheets making spooky noises whenever they see the words "Remote Code Execution." The report here is that glibc has this huge, terrifying attack surface turning any application into a hacker back door paradise; that assessment is false.

        Did you hear about CVE-2015-1473, allowing a local or remote user to trigger a denial-of-service in glibc

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close