Slashdot Mirror
Critical Kerberos Flaw Revealed
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."
For a minute, I almost wondered if the actual cryptosystem had been broken, but then I realized that this is only the implementation of it. There's a *big* difference...
:]
Fortunately, all we have to do is download a patch, which is much better than having to find something other than Diffie-Hellman key exchange...
That means it does not hurt the opensource version of Kerberos V, heimdal because it does not support Kerberos IV which is supported by KTH.
As a user on a network that uses Kerberos authentication, it's good to know about these security flaws. That way, we can email the admin to find out if we should unplug our CAT5. :-)
..on stories like this is if you'd just put some short thing telling how to determine if you are affected by the security hole.
/sbin/sshd --version and it says your version is 2.23 or lower, you're affected".
:)
like, just say "if you type
A lot of the time it's kind of hard to remember which version exactly you have, and much UNIX software offers no quick, clear way to tell what version you have installed. Hell, i don't even know if i have kerberos. I know i've never consiously used kerberos. But for all i know my linux distribution installed kerberos as part of another package. Now i, and a bunch of other people, are going to be poking around manpages and wierd directories for awhile trying to figure out, uhh, do we have kerberos, what version/brand, do we need to disable or patch anything.. this is not the hardest thing in the world, but it isn't exactly easy when you consider it's 11:12 PM and at my college, we start drinking on thursday night. I'm not exactly in the mood to think logically at this exact moment.
So, a quick 'heads up, here's the quick way to tell if you're affected' on the part of the slashdotty people at the end of these story blurbs would be much appreciated
Whoa, reading this title I thought maybe it was an actual flaw in the protocol! But it's just a buffer overflow. At least ZDNet put "critical" in quotes.
So all I have to do is update the software and I'm good to go. Just like any other buffer overflow.
Actually I don't use Kerberos at all, so it really doesn't matter. But the title really caught my attention..
Kerberos makes it really difficult to do any work at MIT. It's a software product designed by faculty to slow up research projects by students.
The reasons for this are twofold: ensure longer paths to tenure, and keep smart students from publishing too quickly and making their profs look bad.
-- clvrmnky
Hrm....I haven't noticed anything about this on Bugtraq or Full-Disclosure, and you'd think that something this big would be all over those lists about two or three days before it got posted here. I'll believe this when I see a proof-of-concept.
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
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
Well, Microsoft is currently working on their own implementation of Kerberos, Microsoft Kerberos. I've seen about a half-dozen root exploits for MIT kerberos, but none yet for MS kerb. I guess this is really a first for the boys in blue. ;]
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Kerberos is a three-headed dog that guards the gates of hell. A flaw in Kerberos is a serious situation because if it fails, all hell could break loose.
I completely agree. I say that people wait until the respective worm comes out for the said vulnerability, then post an article about that, where hundreds of /. comments will mock stupid people for not patching their systems. =)
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Stack overflow, stack overflow... Better create an architecture and/or compiler where is NO stack at all! Be much more secure then.
---
How is everybody spent todays' slashdot meetup?
The patch is available here.
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!
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
If only we were all using Windows this could have been avoided. :(
NO CARRIER
If you don't like the article, then skip it. Stop posting shit like this, thereby increasing the signal to noise ratio. No one ever claimed that every slashdot article is going to interest everyone. This one is aimed at the more technical crowd, and gives people a chance to talk about kerberos.
-- gid0ze
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.
It doesn't matter what you do...some part of your security solution is going be broken by some hackers at some point. Get used to it, deal with it.
Me, I spend the money my boss gives me for security on beer and better video cards for my office mates that like unreal tournament.
Oh, I should also mention that in addition to not providing any type of network secuity you must also not supply any type of network monitoring. Can you imagine...you're two frags from godlike and some system monitor (that you don't understand anyway) starts paging your beeper like a crazy x-girlfriend.
You might just lose concentration.
Here before all but 8486 of you.
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!)
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/
If we're going to have articles on what dangerous server rooms look like, we can have an article on how if you don't patch that KDC server fast, tens of thousands of user accounts might be compromised. Kerberos is at the HEART of many large multi-user distributed systems. (Universities, hospitals...) A critical flaw possibly compromising hundreds of thousands of accounts worldwide is a big story.
"We're smart, we're careful, we can write code in C that doesn't have buffer overflows." Yeah, right. If MIT hackers can't do it, if Microsoft can't do it, who can?