Slashdot Mirror

← Back to Stories (view on slashdot.org)

Critical Kerberos Flaw Revealed

Posted by CowboyNeal on from the locking-down-the-network dept.

doi writes "ZD Net is carrying a story about '...a critical flaw that could allow hackers to circumvent the secure networking system...The problem lies with software in MIT Kerberos 5 called kadmind4 (Kerberos v4 compatibility administration daemon), which allows compatibility with older administrative clients. A buffer stack overflow allows an attacker to use a specially formed request to gain access to the KDC with the privileges of a user running kadmind4.' It affects all MIT-derived versions of Kerberos 4 and 5."

22 of 197 comments (clear)

  1. Old news by Anonymous Coward · · Score: 2, Informative

    This has been known for awhile. The OpenBSD errata contained a patch fixing the flaw in the 3.0 and 3.1 releases three days ago.

  2. Re:Question by cscx · · Score: 3, Informative

    Kerberos explanation up in he'a!

  3. Re:Question by carpe_noctem · · Score: 5, Informative

    In all seriousness, Kerberos is basically a really cool idea for a distributed system of authorization. My college uses it (in combination with OpenAFS) for pretty much all campus-wide services. The idea is pretty straight forward: when you authenticate to the network, you don't want to have to type in your password once to get email, again to get into your home directories, again to get into protected webspaces, and so forth. One password should let you into everything. Likewise, you should be able to just change your password once, and have this change propagate to all the appropriate servers that you want to authenticate to.

    That being said, here's kerberos in a nutshell. You log on to the network, and authenticate with the main kerberos server. This server grants you a "ticket", which you just pass to the machines you want access to. After so long, your tickets expire and you'll need to re-authenticate. (It would be bad if you left your desk for work, and evil joe cracker stole your ticket during the night and read your email and so forth). There's really a lot more to kerberos then that, but the basic idea is that you authenticate to one machine, then use that machine to authenticate to any other machine on the network. It's a rather nice way of doing things, but it is pretty much overkill for anything less than a network of at least 100 users.

    --
    "Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
  4. Re:it is only MIT Specific � by KevinM · · Score: 4, Informative

    Assuming your heimdal is built without kerberos4 compatibility. See: http://www.pdc.kth.se/heimdal/

    Also, note that the vulnerability is not just theoretical.

  5. patch available by fat32 · · Score: 5, Informative

    The patch is available here.

  6. ...and when you stop laughing... by km790816 · · Score: 3, Informative

    From our friends at MIT: Kerberos: The Network Authentication Protocol

    --
    A speech...
  7. So.... don't run kadmind4? by Benley · · Score: 4, Informative

    So basically, all you have to do to avoid the vulnerability is just not run kadmind4, correct? I certainly can't speak for other KDC admins, but I haven't had much of a use for krb4 compatibility for a long time now - I disabled it at LEAST a year ago. Are there still many systems and/or applications that don't support Kerberos5? In any event, yay for me, my KDCs are unaffected!

  8. nah by Anonymous Coward · · Score: 5, Informative

    Buffer overflows are wholly in implementation, never in specification.

    I mean, they exist only within the program that they effect. All that a buffer overflow is is that someone was writing a program, and they put in some place that they read a value from one place and put it in another-- say, they have a web server, and they recieve some data from the client requesting a web page. And let's say that when they accept this data, they're going to put it into a little memory space that can hold 2000 bytes. A buffer overflow would be what would happen if the web client sent more than 2000 bytes of data, maybe 3000 bytes, and the program stupidly attempted to fit all 3000 bytes into that 2000 byte space. What you get is a buffer overflow; quite literally, that 2000-byte buffer "overflows", spilling an extra 1000 bytes of data into memory. The problem is that those 1000 bytes of memory it overwrites could quite possibly contain very important things. So if you exploit a buffer overflow by accident, say by sending a server more information than it can handle, you'll probably get a crash. But if you know a bit about the way that the program with the buffer overflow bug works, you can do some kind of clever things-- for example, you could send 3000 bytes, but very carefully sculpt those last 1000 bytes so that the program keeps running, doesn't crash, but suddenly has a bunch of your information in its memory. Do this right (hulk smash stack! smash!), and you can
    literally send a very small program into the memory of the server and trick the server into running this program.

    Now, this is a programming error; you can't build a buffer overflow into a protocol. Why? Because it's just a programming error. In our example above, the programmer of the web server made the mistake of not taking steps to prevent a buffer overflow. And preventing a buffer overflow is *easy*; you just make sure that whenever you copy data from one place to another, that you never put into a single memory space more data than it can hold. Like, you're writing that web server, and you have a network socket through which the client is sending you a request? Use fgets(SOCKET, space, 2000); instead of gets(SOCKET, space); (i think that's the right syntax). fgets() is a special version of gets(), with the special condition that you can give it a number of bytes and say "if the data coming in from this filehandle is more than this number of bytes, i don't want you to give me the rest". So fgets() will just read in 2000 characters and then stop, preventing a buffer overflow. It's that simple, you just carefully pick the ways in which you copy memory. the problem is that C is hard and people are lazy and people keep doing things like using gets() and lazily coding their fscanf() statements.

    Now, there is one sort-of-exception to my "you can't code a buffer overflow into a protocol" rule: AOL actually did! That is to say, at one point AOL was trying to figure out how to lock Jabber and MSN users out of using the OSCAR protocol to access AOL instant messenger. (Third party clients are supposed to use TOC instead.) So AOL looked at their program and realized, hey, we accidentally put this buffer overflow in this one place in our AIM client, and neither MSN or jabber have that overflow. So (and they may have undone this change since then, i don't know, it was a wierd month) they changed the OSCAR protocol to the point where you literally can't connect to AOL instant messenger without that buffer overflow there! Becuase the OSCAR server would buffer-overflow-attack the AIM client, and send it code where, if the overflow was successful, the AIM client would send back a specific packet. If the OSCAR server didn't get this packet, it would disconnect you. Creepy, huh? Now, this wasn't very unsafe, becuase the way that the client was set up the only way that the buffer overflow could be exploited was by data recieved from AOL's computers.. but, then, it was also pretty stupid, becuase the buffer overflow was still exploitable by someone doing a man-in-the-middle attack and impersonating AOL's servers!

    But, uh, yeah, that story doesn't have anything to do with backward-compatibility. kerberos didn't have to have the buffer overflow to bebackward compatible, that just isn't the way protocols work. i am guessing the overflow cropped up in backward-compatibility code because one, backward-compatibility code is usually really, really nasty and hard to debug, and two, it's possible that the backward-compatibility code in v5 could have been largely copied out of v4, and the code with the buffer overflow copied along with it.

    That answer your question any?

    Yeah. You see? you see all this typing above?? this is the extents i will go to to find some distraction so that i don't actually have to do my homework. God, remind me never to go to grad school, i'd never get my thesis even started.

    --super ugly ultraman

    1. Re:nah by psamuels · · Score: 5, Informative
      There is something else that I would like to know. Since a buffer overflow attack overwrites with data memory addresses filled with instructions, why not designing an operative system that isolates the executable memory from the data memory?

      This is theoretically a good idea - and in fact it has been done as a Linux patch, more than once. Google for "solar designer" linux non-executable stack. There are a couple of problems:

      • Some code needs to be able to write a stream of instructions that it will then jump to. This is called a "trampoline" and can accomplish tricks which are otherwise difficult to do within the confines of a compiled language. I think GCC emits trampolines for certain C++ constructs on certain architectures, but I seem to remember there was some noise made awhile back about migrating to other methods so as to work with non-exec stacks.

        Just-in-time (JIT) compilers for languages such as LISP and Java have to be able to write executable code at runtime, though it's not really called a trampoline in that case.

      • It is possible to exploit a buffer overflow without actually executing code directly. Hard to explain, but the gist is that you overwrite bits of the stack which represent the function return address, so that the function "returns" to somewhere other than where it came from - say for example into the C library's system() function. Craft the rest of your overflow properly and you can dictate the arguments to said function - say system("/bin/sh").

        I believe it has been demonstrated that any buffer overflow which can be exploited to execute code directly can also be exploited to execute code via the indirect method outlined above. At least on certain architectures. RTFG.

        So, if Linus (for example) were to incorporate Solar Designer's non-exec stack patch into the Linux kernel, the exploit writers of the world would spend a week or so re-learning how to build buffer exploits to use nonexecutable means.

      This is the main reason people oppose the non-executable stack patches. If widely used, we would in the long run be no better off than before. The added complexity in the Linux kernel would buy nothing. Naturally, those who have to battle kernel complexity generally oppose it. But - note that as long as only a few people use Solar's patch, they are better off, because the exploit writers do not focus on them. (Same reason there are more viruses for Windows than for MacOS 9, which had little significant virus resistance.)

      Ahem. I also feel compelled to mention (since someone else will if I don't) that in combination with other techniques, such as relinking libraries with random load addresses on each machine, the non-exec stack patch may actually be effective. I am nowhere near enough of an expert to say for sure. (Jakub Jelinek's ELF prelinker sounds rather interesting in that context....) Also, architectures (like the HP PA-RISC) whose stacks grow upward instead of downward are probably resistant to most common buffer overflow techniques, but again I don't have the skillz to say whether such techniques could be adapted.

      --
      "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
    2. Re:nah by kiolbasa · · Score: 2, Informative

      Since a buffer overflow attack overwrites with data memory addresses filled with instructions, why not designing an operative system that isolates the executable memory from the data memory?

      The x86 is what we call a Von Neumann (maybe not spelled that way) architecture machine, meaning memory is memory and you can put whatever you want there. A Harvard architecure machine separates program and data memory. There are tradeoffs and advantages to each architecture.

      The operating system you suggest running on a Von Neumann machine would essentially emulate a Harvard machine on hardware not designed to do that. To avoid buffer overflows, just use a Harvard machine with an OS designed for it. But you lose the advantages of a Von Neumann machine, like self-modifying code, simpler executable formats, simpler memory management.

      In simple terms, all your questions could be answered with "It's a hardware thing."

      --

      Beer wants to be free
    3. Re:nah by davidstrauss · · Score: 4, Informative
      The fix is to design the CPU so it refuses to run code in an area designated as stack space...

      Not to say the argument isn't entirely valid, but Microsoft uses this as an argument for Pallidium and "trusted" code. Be cafeful about asking for restrictions on how code can run on a user's computer.

  9. actually, this is old news (of sorts) by fat32 · · Score: 3, Informative

    Actually, this security advisory (from the list) states that "Serious buffer overruns exist in krb4 compatibility code." It's not dated, but from reading it, it must be from at least six patches ago.

    In other words, this latest advisory is the *first* specific bug of this type found since the problem was first discovered (and numerous other bugs of this type have presumably been fixed by now).

    I think it's safe to assume that it won't be the last, so if you really want to be secure, take the original advisory to heart and avoid krb4 compatibility code.

  10. Kerberos does not use Diffie-Hellman by dido · · Score: 5, Informative

    Just a slight nitpick, but AFAIK, Kerberos never used any public key cryptography at all, Diffie-Hellman or otherwise. They use the Needham-Schroeder key exchange protocol which only requires symmetric key cryptography.

    --
    Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
    1. Re:Kerberos does not use Diffie-Hellman by Xenographic · · Score: 2, Informative

      You're right, Kerberos is based on Needham-Schroeder key exchange (see http://www.upenn.edu/computing/pennkey/docs/kerbpr es/siframes.htm), but you might want to double-check that nitpick...

      Diffie-Hellman Key Exchange for Kerberos V5

      Abstract

      The Kerberos protocol [RFC1510] currently establishes session keys by the assertion of one party (usually the KDC). This document describes a method for using the Diffie-Hellman algorithm to establish the shared secret between a Kerberos client and application service. For the purposes of this document, the Ticket Granting Service is considered an application service.

      [excerpted from --
      http://www.ietf.org/proceedings/99mar/I-D/draf t-ie tf-cat-kerb-dh-key-exchange-00.txt ]

  11. Why this is big.... by fortinbras47 · · Score: 5, Informative
    Kerberos is the security core of some very large systems.... For example at the University I attend, logins on all accounts on the campus wide computing infastructure are done through kerberos. AFS file system tickets are done with kerberos. Authentication for logging into class registration is done through kerberos. And the list goes on. If someone managed to root one of the main kdc servers and compromise a bunch of accounts, the person could create mischeif on a rather large scale.

    I wonder how much you could do before you got noticed, but even if you managed to copy over the encrypted password files, I'm sure you could find some that fell to cracking software.

    The ramifications of a flaw in a kerberos implementation is a great deal more important than a flaw in outlook. (The importance of this though means this flaw is probably going to be patched faster than a speeding bullet!)

  12. Re:Nawww.... by nelsonen · · Score: 5, Informative

    It's called Burroughs/Unisys MCP Stack Architecture. :-) Been around since the mid 60s. Bounds checking down to the array level, hardware enforced, with hardware enforced data/code seperation.

    http://public.support.unisys.com/aseries/docs/ha rd ware/70205547-001.pdf is the current architecture document.

  13. kadmin4 has a history of buffer & security bug by dananderson · · Score: 5, Informative
    kadmin4 has a history of buffer overflow and security bugs.

    Unless you need backward compatibility with Kerberos v4 (most people should use v5 nowadays), disable it.

    Lose kadmin4 and disable starting krb524d in /etc/init.d/

  14. Re:Question by Anonymous Coward · · Score: 3, Informative

    standard disclaimer: the following may not be exactly what goes on, as it's only as I remember it. I don't work with it, but I use it.

    One really nice part of Kerberos is that your password never used. When you authenticate, the authentication server encrypts your ticket with your password as the key. So, your password NEVER passes over the network. If you put in the right password, then it's decrypted just fine, and you have your ID with you.

    The other unique part of Kerberos is that the servers must also prove their identity. When you ask the mail server for your mail, it asks the auth. server if you are who you say you are, and the auth. server will verify that you're a user on the system. Only a mail server with it's own ticket to the kerberos auth server can do this. Therefore, the mail server doesn't have to touch your password, and you can be certain that the mail server is safe to use.

    The idea is that all transmission of your personal data is minimized, and restricted to trusted sources only.

  15. Re:Oh No... by CommanderTaco · · Score: 2, Informative

    umm... this flaw affects the server, not the client, so they would only have to patch the few server machines...
    but even if there was a security patch that needed to be applied to all public workstations, there is an automatic update deployment procedure... so no, sysadmins wouldn't ever have to go from computer to computer, replacing software...

  16. Re:it is only MIT Specific � by yak · · Score: 2, Informative

    The only export restriction is this:

    Export of software employing encryption from the United States of
    America may require a specific license from the United States
    Government. It is the responsibility of any person or organization
    contemplating export to obtain such a license before exporting.

  17. Re:M$FT too? by vandy1 · · Score: 2, Informative

    No. M$FT only has a butchered Kerberos V implementation; there is NO Kerberos IV support.

    Note that this only affects you if you have enabled Kerberos IV backward compatibility support.

    Michael

  18. Re:C programming by HiThere · · Score: 3, Informative

    Languages without buffer overflows:
    Ada*, Python, Ruby, Pascal, Clean (well, that's windows only), Eiffel, OCaML, APL, PL/1**.

    Some of these languages are relatively slow. Ada is as fast as C, and as powerful as C++, but a pain to learn. Eiffel differs greatly between implementations, and is *extremely* dependant on how you specify compile time options. If you have all possible checks on, then it is slow. If you turn them off, then it is fast. And you can fine-tune it so that some routines have check on and others don't. Python and Ruby are "reasonably fast", but certainly not speedy. I don't know Clean or OCaML, but for some things OCaML is quite fast. APL is... well, it's APL. The original write-only language. I never learned it well, so I can't speak to it's advantages and disadvantages, but at one point CDC was considering choosing it as the language that it's STAR computer would be designed for. I think that meant that a macro processor would be able to translate it into the binary, but I'm not sure. So it must have some capabilities as a systems language.

    * In Ada you can have buffer overflows, but it takes extra work. No automatic garbage collection however.
    ** In PL/1 it depends on the kind of variables allocated. Your programming style determines whether or not buffer overflows are prohibited. But this doesn't mean the kind of constant attention that C requires, as you can control it at variable declaration time.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.