Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Minix 1.5 password insecurity

34 views
Skip to first unread message

koos van den hout

unread,
Nov 29, 1992, 4:40:06 AM11/29/92
to
First of all, I _know_ Minix isn't meant as a secure system, only for
educational purposes.

But the fact is I have a program source here which decrypts Minix 1.5
passwords.

You simply type :

$ decrypt root
The password for root is 'Geheim'.
$

(I did not write this program myself.)

The program simply reverses the whole bit encryption process.

I'm not going to post it right away, but when there's interest, I'm willing
to post it or mail it to interested persons.

Grtx. KH

/-- Koos van den Hout ----------------------------------------------- Sysop --\
| Student Computer Science (AKA HIO) BBS Koos z'n Doos (+31-3402-36647) |
| Inter-: ko...@kzdoos.hacktic.nl 300..14400 MNP2-5,10,V42bis) |
| net : vande...@ruumtc.tcu.ruu.nl Fido: Sysop @ 2:500/101.11012 |
| Surfnet RUUMTC::VANDENHOUT |

James Abendschan

unread,
Nov 30, 1992, 10:47:58 PM11/30/92
to

In a previous article, ko...@kzdoos.hacktic.nl (koos van den hout) says:

>First of all, I _know_ Minix isn't meant as a secure system, only for
>educational purposes.
>
>But the fact is I have a program source here which decrypts Minix 1.5
>passwords.
>

As I understand it, as MINIX is an internationally distributed product,
there are some lame export laws which don't allow the "normal" DES UNIX
encryption algorithm to be distributed outside the US; thus the
"crippled" version in MINIX. There is a fix on plains.nodak.edu whihc I
think contains a slightly more secure algorithm..

>
>I'm not going to post it right away, but when there's interest, I'm willing
>to post it or mail it to interested persons.
>

Well, as most sites that run an "open" system *should* have the fix, I
don't know if it would do any good.. but I imagine it would wake a few
sleepers :)

Al Donaldson

unread,
Dec 2, 1992, 9:01:06 AM12/2/92
to
In article <1fen9e...@usenet.INS.CWRU.Edu> bf...@cleveland.Freenet.Edu (James Abendschan) writes:
>As I understand it, as MINIX is an internationally distributed product,
>there are some lame export laws which don't allow the "normal" DES UNIX
>encryption algorithm to be distributed outside the US; thus the
>"crippled" version in MINIX.

I can't argue with this reaction to US policy -- makes sense to me, if
you're gonna write code that a US company is going to distribute, then you
don't want to do something that will put some PH vice president in jail..). :-)

But I do wish it had been a little more widely known. From 1989 onwards,
I spent a *lot* of time reading everything about MINIX I could get my hands on.
And I never saw anything on reversible passwords until 1990. I ended up with
a not inconsiderable amount of egg on my face because I didn't know of this
problem when someone was paying me to know about things like that. I just assumed..
(but you know what "assume" is, don't you, makes an "ass" out of "u" and "me").

Here's what we did. I grabbed Phil Karn's KA9Q public domain DES package
and my associate wrote a layer of code that packages up the password strings
and calls desinit() and endes().

I would much prefer that Andy and PH would have taken this position, openly.
Leave in the reversible DES so encrypted password strings look sorta real,
but write crypt() so individuals can get DES and plug it in.

Al

Will Rose

unread,
Dec 2, 1992, 10:22:11 PM12/2/92
to
a...@escom.com (Al Donaldson) writes:

>In article <1fen9e...@usenet.INS.CWRU.Edu> bf...@cleveland.Freenet.Edu
>(James Abendschan) writes:
>>As I understand it, as MINIX is an internationally distributed product,
>>there are some lame export laws which don't allow the "normal" DES UNIX
>>encryption algorithm to be distributed outside the US; thus the
>>"crippled" version in MINIX.
>
>I can't argue with this reaction to US policy -- makes sense to me, if
>you're gonna write code that a US company is going to distribute, then you
>don't want to do something that will put some PH vice president in jail..).
>

>But I do wish it had been a little more widely known. From 1989 onwards,
>I spent a *lot* of time reading everything about MINIX I could get my hands on.
>And I never saw anything on reversible passwords until 1990. I ended up with
>a not inconsiderable amount of egg on my face because I didn't know of this
>problem when someone was paying me to know about things like that.

What sort of Minix system were you using, that you could rely on password
security for protection? As far as I know, most Minix systems have no
memory management, and bootable floppies are readily available. In these
circumstances, uids and passwords are just a convenience, to stop you
messing up files you don't want touched. Is there a secure Minix system
somewhere?

Will
c...@crash.cts.com

Thijs Kaper

unread,
Dec 3, 1992, 5:11:09 AM12/3/92
to
>In article <1fen9e...@usenet.INS.CWRU.Edu> bf...@cleveland.Freenet.Edu (James Abendschan) writes:
>>As I understand it, as MINIX is an internationally distributed product,
>>there are some lame export laws which don't allow the "normal" DES UNIX
>>encryption algorithm to be distributed outside the US; thus the
>>"crippled" version in MINIX.

Hello, there,

I haven't been following this group for some time, so i drop in in the middle
of this discussion.
My solution to this "problem" was the following:

* Make a copy of your /etc/passwd file to /etc/passwd.sec
* Set read permissions of /etc/passwd.sec to ROOT only
* Delete all passwords from the original copy, and replace with a "*"
* Modify the (two??) library routines that read or write /etc/passwd
in a way that /etc/passwd is used for "normal" users, and that
/etc/passwd.sec is used for all ROOT-permission programs. (effective uid)
* Don't forget to recompile the programs which use these library routines
(passwd, login, su,...?)

If you finished processing this list, your /etc/passwd file doesn't
contain any usefull hacking information anymore. It's just used for
programs like ls to identify users. So actually no encryption at all
is needed (but it's safer to keep the encryption).

Of course you could create some programm's to maintain your multiple
passwd copies. My approach to this was to make a programm which
copies /etc/passwd.sec to /etc/passwd, leaving out the passwords...

Allright I can't give you a solution if you just wanted to ebcrypt some
datafiles. But my passwd file is as far as the passwords are concerned
reasonably safe...

If this approach sounds interesting, and you can't get it working on your
system, you can ask me (by follow-up?) to look up my changes in library
functions. But the modifications weren't too hard to make...

Greetings,
Thijs Kaper
(Student electronics/computer-technics)

P.S. I got this idea from the HP9000 i'm typing on currently...


--
=========================================================================
Thijs Kaper , Alkmaar , Holland , Europe Email: th...@titan.hts.hsa.nl
(To_be) OR (NOT To_be) is digitally true...
=========================================================================

Paul Mather

unread,
Dec 3, 1992, 12:53:42 PM12/3/92
to
Al Donaldson (a...@escom.com) wrote:
> Here's what we did. I grabbed Phil Karn's KA9Q public domain DES package
> and my associate wrote a layer of code that packages up the password strings
> and calls desinit() and endes().
>
> I would much prefer that Andy and PH would have taken this position, openly.
> Leave in the reversible DES so encrypted password strings look sorta real,
> but write crypt() so individuals can get DES and plug it in.

An even better alternative is to use the public domain and freely
distributable MD5 cryptographic hash function as the basis of your
crypt() function. That way not only would you overcome the problem of
redistribution (MD5 is not export-restricted like DES, and can be freely
ftp'd from, amongst other places, rsa.com), but also you gain the huge
advantage of allowing users to have arbitrary length pass PHRASES
instead of just 8 char passWORDs. This makes brute-force
dictionary-based password cracking largely infeasible[*].

Diolch yn fawr,

Paul.

[*] Of course there will always be naive users who choose bad passwords,
but pass phrases make it far easier for them to choose good ones
instead. IMHO.
--
e-mail: p.ma...@sees.bangor.ac.uk

If your mailer can't reach me, I'm obviously not worth talking to.

Bruce Evans

unread,
Dec 6, 1992, 10:05:35 AM12/6/92
to
In article <1992Dec02.192212.17526@crash> c...@crash.cts.com (Will Rose) writes:

>What sort of Minix system were you using, that you could rely on password
>security for protection? As far as I know, most Minix systems have no
>memory management, and bootable floppies are readily available. In these

All Minix 1.5 systems running on 286's, 386's and 486's have sufficient
memory management for security. There may be a few kernel bugs that cause
insecurity but these are insignificant compared with the password security
holes.

No system is secure against physical attacks like booting a floppy.
--
Bruce Evans (b...@runx.oz.au)

Pete French

unread,
Dec 1, 1992, 9:55:28 AM12/1/92
to
From article <gate.J09...@kzdoos.hacktic.nl>, by ko...@kzdoos.hacktic.nl (koos van den hout):

> You simply type :
>
> $ decrypt root
> The password for root is 'Geheim'.
> $

the solution is to simply drop in a UNIX crypt into the source - I kept the
one from minix 1.1 and still use that. There are lots lying around if you
look - a nice fast one comes with COPS if you want speed.

-bat.

--
-Pete French. (the -bat. ) -+ Skin Up 4 Jesus !
Adaptive Systems Engineering |
+- Tuktusiuriagatigitqingnapinngitkyptinnga!

0 new messages