Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
QNX / iOpener crypt() broken

By raph in News
Sun Apr 16, 2000 at 03:37:27 AM EST
Tags: Security (all tags)
Security

It looks like QNX decided to implement their own passwd() algorithm instead of using the standard Unix version. As is often the case with home-brewed, non-peer-reviewed crypto, it is totally insecure. Source code to break it is on www.i-opener-linux.net.

This apparently affects the Netpliance iOpener, as well as probably most other QNX-based devices. Quite a number of nontrivial passwords have been posted already.


This isn't really a free software story, but it does highlight one of the serious risks of not using free software. Obviously, a fiasco like this would never happen with Linux or any of the BSD variants.

Thanks to Peter Gutmann for posting a heads-up to cypherpunks. This story is also posted on Advogato, but I thought the readership here would be interested as well.

There is a story at Slashdot describing a potential vulnerability in Microsoft FrontPage Extensions 98. It's not at all clear to me what the substance is of these claims, though.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Slashdot
o www.i-open er-linux.net
o posted
o Advogato
o story
o Also by raph


Display: Sort:
QNX / iOpener crypt() broken | 21 comments (21 topical, editorial, 0 hidden)
Interesting. On my system, however,... (1.00 / 1) (#3)
by xah on Sat Apr 15, 2000 at 09:36:36 PM EST

xah voted -1 on this story.

Interesting. On my system, however, the HTML appears to be broken. The article text is not wrapped on the screen.

Good story, fix the links.... (none / 0) (#8)
by alisdair on Sat Apr 15, 2000 at 09:47:38 PM EST

alisdair voted 0 on this story.

Good story, fix the links.

Bad links and random security news.... (none / 0) (#9)
by bgp4 on Sat Apr 15, 2000 at 09:48:32 PM EST

bgp4 voted -1 on this story.

Bad links and random security news.
May all your salads be eaten out of black hats

That's very very bad. This would ap... (4.00 / 1) (#1)
by rusty on Sat Apr 15, 2000 at 10:03:43 PM EST

rusty voted 1 on this story.

That's very very bad. This would appear to be the second major blunder from netpliance. One wonders about their future...

____
Not the real rusty

Re: That's very very bad. This would ap... (none / 0) (#15)
by medicthree on Sun Apr 16, 2000 at 03:51:25 PM EST

Well, one could only call this a "blunder from netpliance" if one would say that in any case of encryption being cracked that it's a "blunder" on the part of the person / entity that wrote the encryption. Maybe the encryption wasn't up to par. Maybe it was a normal level and it just got cracked because many people were motivated to do so. I'm not sure how much this reflects on Netpliance itself.

[ Parent ]
Re: That's very very bad. This would ap... (4.00 / 2) (#16)
by rusty on Sun Apr 16, 2000 at 03:59:24 PM EST

Reading the story more carefully, it was a blunder on the part of QNX, more than netpliance. And yes, "blunder" is the word here, because this is not just any case of encryption being cracked. This is a *really* well-understood algorithm, with many well-tested free implementations. Writing your own implementation of something like unix crypt() is, all by itself, already a blunder. Having is cracked (hell, even having it crack-able) is a major blunder.

____
Not the real rusty
[ Parent ]
One-way 128-bit hashes are good. A... (4.00 / 1) (#7)
by fluffy grue on Sat Apr 15, 2000 at 11:11:50 PM EST

fluffy grue voted 1 on this story.

One-way 128-bit hashes are good. A lot of companies have yet to figure out that the point to password authentication is to authenticate the password in a way that you can compare them in crypted-text space, and NOT in plaintext space. All these problems would be solved if everyone just used md5 and compared the md5 hashes instead of using a (usually insecure) symmetric crypt() function.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

While I usually don't like Slashdot... (none / 0) (#6)
by evro on Sat Apr 15, 2000 at 11:48:17 PM EST

evro voted 1 on this story.

While I usually don't like Slashdot references in stories, this one was great. While I don't agree with everything ESR has to say, the essay on Slashdot highlighted one of the best reasons to use open-sourced software. As a side note, I emailed ESR and asked him why he sent that article only to Slashdot, since that was just preaching to the choir, and he replied saying he *had* sent it to more mainstream media. Now it's up to them to pick it up. If this gets to the WSJ or NYT (or CNN) I'll be impressed. This is the kind of thing that Average Joe doesn't realize, and it's incredibly important. Even if a company doesn't "embrace" the "Open source movement," I still think they should round up some top hackers, show them the source, and let them do their worst to try and break it. I think it's worth noting that they didn't have to use "free" software -- they just had to use an existing, proven implementation. Why they would choose not to do this baffles me. Does anybody have any stats on how long it would take to crack an 8 character, alphanumeric+punctuation password using the standard crypt()?
---
"Asking me who to follow -- don't ask me, I don't know!"

Re: While I usually don't like Slashdot... (none / 0) (#12)
by TomG on Sun Apr 16, 2000 at 06:29:34 AM EST

It's DES. 56 bit. 22 hours is the record. =)

[ Parent ]
Re: While I usually don't like Slashdot... (none / 0) (#13)
by rusty on Sun Apr 16, 2000 at 12:04:23 PM EST

I first read that essay on Linux Today. Of course, now it appears that the "hole" never existed at all. Check the updates on various sites (Ars Digita, et al). Still, ESR's point stands, I think. This is the kind of thing that *could* happen in closed software, and *couldn't* in open source.

____
Not the real rusty
[ Parent ]
hole (none / 0) (#20)
by vipw on Sun Apr 16, 2000 at 07:54:13 PM EST

the netscape engineers are weenies(backwards) was not a backdoor. however, the the dll in question apparently has a buffer overflow, presumably caused by a strcpy(). ms engineers may not be weenies, but they sure aren't very careful :)

[ Parent ]
Re: hole (none / 0) (#21)
by rusty on Mon Apr 17, 2000 at 12:08:20 AM EST

However, buffer overflows are found in open-source software too, all the time. It's the kind of problem that can be overlooked, even if you have source. Too few people (where "people" == "non-programmers") understand the difference between these types of problems. It's good that ESR jumped on the example, even if it didn't turn out to be the emergency that everyone thought.

And, I don't know... JWZ might be a little bit of a weenie. ;-)

____
Not the real rusty
[ Parent ]

Typical. (none / 0) (#18)
by Anonymous Hero on Sun Apr 16, 2000 at 04:41:51 PM EST

Mainstream media throw any writing on free software related issues straight into the bin. My experience too. Hope that when they find out whom they wastepaperbinned this time, they are duly ashamed ;-)

[ Parent ]
This isn't really a free software s... (1.00 / 1) (#10)
by Eimi on Sun Apr 16, 2000 at 12:16:41 AM EST

Eimi voted 1 on this story.

This isn't really a free software story, but it does highlight one of the serious risks of not using free software. Obviously, a fiasco like this would never happen with Linux or any of the BSD variants.

Why not? It seems that Linux and the BSDs are just as likely to have security flaws found in them. The difference is mean-time-to-patch with open systems.

Re: This isn't really a free software s... (none / 0) (#17)
by mattdm on Sun Apr 16, 2000 at 04:23:59 PM EST

Yeah, but hopefully this particular kind of flaw would have been fixed long long ago.

[ Parent ]
Once again, lack of proper peer rev... (none / 0) (#2)
by Inoshiro on Sun Apr 16, 2000 at 12:22:35 AM EST

Inoshiro voted 1 on this story.

Once again, lack of proper peer review has caused problems. I really don't understand why business people are so untrusting. Science has come very far in the past few hundred years thanks to peer review, as have the OpenSource projects.

--
[ イノシロ ]

People say this could never happen ... (none / 0) (#4)
by FlinkDelDinky on Sun Apr 16, 2000 at 01:25:14 AM EST

FlinkDelDinky voted 1 on this story.

People say this could never happen on Linux. Whenever I hear this I always think never say never.

I think Linux is secure, or so I hear, if the sysop sets things to be secure. IIRC Redhat shipped with somekind of security issue for quite a while.

Hole, yes. Fiasco, no. (5.00 / 1) (#11)
by raph on Sun Apr 16, 2000 at 04:18:44 AM EST

I am not saying that Linux is perfectly secure. In fact, the fact that your shiny new RedHat 6.2 CD contains (by my seat-of-the-pants estimate) about 100 exploitable holes concerns me greatly. What open source prevents is a problem this stupid. Anyone with any clue whatsoever about security would tell you that replacing a well-known security primitive with a new one is asking for trouble. Thus, the problems shipping with Linux are of the subtle, harder to find, and often systemic kind. The really dumb ones have all been taken care of.

[ Parent ]
I went and checked QNX's website an... (3.00 / 3) (#5)
by kraant on Sun Apr 16, 2000 at 02:51:45 AM EST

kraant voted 1 on this story.

I went and checked QNX's website and not suprisingly there seems to be no information on this turn of events... Interestingly enough QNX has become a charter member of the embedded Linux Consortium which is something I hadn't heard about...

I wonder how it will affect future development. Particularly whether companies will pay more attention to the various small opensource OSs out there like

  • v2os A 386+ os written entirely in assembly targeted at embedded applications (Pretty much aimed at exactly the same target as QNX
  • small BSD which interestingly enough has had large numbers of people trying to port BSD over to the i-openers on it's mailing list lately
  • And various small distros of linux such as mulinux etc

--
"kraant, open source guru" -- tumeric
Never In Our Names...
Further information (5.00 / 1) (#14)
by Inoshiro on Sun Apr 16, 2000 at 02:56:46 PM EST

Since some people where are not as versed in crypto knowledge as some others, I'm going to talk about a few things I'll also include in tomorrow's article a bit early ;-)

First off, modern user authentication systems never store the value of the password. Instead, they store the value of a hash function. A hash function is a one-way mathematical function that takes a variable size input, and produces an output that is a fixed length. Slackware Linux, Maximus BBS software both use MD5 hashes, Red Hat seems to use DES/crypt hashes, and OpenBSD use Blowfish hashes. The purpose of this is that knowing the hash gives you nothing -- you must know the password, which has to be hashed before it is compared to the database of user hashes.

The problem here is that QNX did not choose a known hash function. Instead they wrote an algorithm which is easy to take in both directions. Because of this, people who can read the passwd file can break the passwords in seconds.

FlinkDelDinky, Red Hat is known for security holes. This is why people generally gravitate towards a more secure package, like Slackware or OpenBSD. TThe reason this is important because there is no other Unix or Unix-alike which allows you do to this.. It is a major security flaw in their design of QNX.



--
[ イノシロ ]
Redhat (1.00 / 1) (#19)
by vipw on Sun Apr 16, 2000 at 07:46:48 PM EST

while redhat has used DES/crypt() in the past MD5 has been the default since 6.0(or maybe 6.1, but i think 6.0). They also set the default to shadowed passwords(putting the encrypted password in a file only readable by root) then. While redhat is far from the king of security, they have at least cleaned up the password storage. Why they include bug-ridden, insecure crap like PAM is beyond me, though.

[ Parent ]
QNX / iOpener crypt() broken | 21 comments (21 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!