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."

Comments

A distinction...

[Xenographic]

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... :]

Re:A distinction...

[dirvish]

Unfortunately, most sys admins will be oblivious to the problem and will not patch anything.

Re:A distinction...

[grungeKid]

Admins (and environments) who use Kerberos tend to be just a bit more clueful than your average admins.

Is this really pertinent?

[6169]

Though this seems to be an increasing trend, do we really need to see bug reports like this on Slashdot, even if they are security related? I can understand if the actual protocol was flawed, but this is just a bug in the admin daemon. If I wanted bug and patch information, I would go to bugtraq, or the OpenBSD security list, both of which covered this days ago.

Re:Is this really pertinent?

[Anonymous Coward]

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

What would really be appreciated

[Anonymous Coward]

..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.

like, just say "if you type /sbin/sshd --version and it says your version is 2.23 or lower, you're affected".

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 :)

Re:What would really be appreciated

[Permission Denied]

Hell, i don't even know if i have kerberos.

Then you're not affected.

This is a bug in the Kerberos admin daemon, which only runs on KDCs, which are centralized Kerberos servers. Clients are not affected. Furthermore, it only affects KDCs that have enabled version 4 backwards-compatibility.

If you don't know what Kerberos is, you don't have to patch your system. Only people that run KDCs have to patch their systems. I've never seen Kerberos installed with less than a few thousand users, so you would probably know if you're the admin of a KDC.

Backwards Compatibility?

[The Rolling Blackout]

Doesn't this illustrate a backwards compatibility problem with secure systems everywhere? As such, buffer overflows that affected any previous system could conceivably affect any & all backwards-compatible systems made after the fact, should such software be afforded the necessary privileges (esp. remote management tools).

(I'm not posting this in an attempt to prove I know anything, I just think a clearly worded reply might benefit a few folks, e.g. me)

Critical Flaw??

[Anonymous Coward]

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..

Re:Critical Flaw??

[blancolioni]

OK, consider a language where every array access is validated. You loop through an array. As a programmer, you know you only have to check the array length once, at the beginning of the loop. The runtime doesn't know this, and thus checks the bounds every time through.

You seem to be thinking in C++ ... yes, the C++ checked array classes are ridiculously slow, because every reference is checked. Here's the Ada equivalent to looping through an array:

for I in Array_Variable'Range loop
-- do stuff with Array_Variable (I)
end loop;

No bounds check required, because the compiler knows that I is always in range.

Furthermore, the ability to restrict variable ranges removes a whole bunch of other bounds checks. You'd be surprised at how little is actually required.

It's also much harder to have buffer overflows with extra-long input; in general, an exception will be raised (in this case by the run time), which, if uncaught, terminates the process. No security risk.

Language design has come a long way since the 1970s. You'd be doing yourself a favour to see what else is out there, even if you never program in anything other than C.

is this for real

[carpe_noctem]

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.

Re:Old news

[6169]

if a security hole came up that affected the integrity of your systems, would you want to know about it now, or say, three days from now?

Then turn off security articles :P

[fortinbras47]

Bugs in critical authetication and login systems, (eg. Kerberos, ssh, etc...) fall into a category critical enough to warrant a ./ story.

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.

Re:So.... don't run kadmind4?

[Martin Blank]

Kudos to you for disabling unused services, but just because something is disabled doesn't necessarily mean you don't need to patch it. Suppose it does need to be enabled, perhaps a year from now, for some temporary purpose, and this vulnerability doesn't cross your mind at the time. Or maybe you won't even be there, and your replacement finds some reason to re-enable it. Whatever the case, finding a reason to not patch it is not a good practice in my mind.

You may sleep easier tonight than some other people, and you may not be racing to log in and patch it like some other admins are, but come the morning you probably should be planning on patching it. But I'm sure that's already on your schedule. :) Of course, if it's not even installed in the first place, then I guess you don't have to worry about it in the first place.

C programming

[g4dget]

"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?

Re:C programming

[Anonymous Coward]

D. J. Bernstein(qmail) can write code in C that doesn't have buffer overflows. ( http://cr.yp.to/djb.html )

Anyone else?

The rest of us should realy use languages like Ada 95, Python, Java, etc...

C was good in the 80th....

Re:Why this is big....

[psamuels]

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.

Just copy the Kerberos secrets database and you can grant yourself tickets to impersonate anyone you want. I am not a Kerberos admin, but I believe in general changing said secret is far from trivial, because every single service provider on the network must be updated.

(This is by design - the whole K architecture is designed around an ultimately trusted KDC which is known to the services via some sort of shared secret.)

Re:nah

[Monkelectric]

hehe your activism is poorly used here. Memory protection is a critical OS concept and has been built into every intel cpu since the 386. The only mechanism needed to keep the CPU from running code on the stack is a list of stack areas :) The same concept keeps programs from accessing other programs memory space in modern OS's (linux, NT/XP, BSD etc). The problem is it protects a program from being overwritten by other programs, not itself :D

Re:So.... don't run kadmind4?

[einhverfr]

On my network we have a process for this--

1-- all unusdes services are disabled
2-- Of course acive services are always patched.
NOTE-- we do not assume that backwards-compatible components to be necessarily patched unless active and maintained by IT.

3-- If we need a backwards compatible patch, we usually upgrade the entire package (testing first, naturally).

4: We keep a database of all vulnerabilities found about our software and how they were resolved. This enables us to query what vulnerabilities are found on inactive services and what computers could be affected.

Look-- the point is plan. There are many ways of doing things, but the point is to have a plan and be thinking about things. Security is more a way of live than a set of precautions.