[techtalk] Re: techtalk digest, Vol 1 #447 - 11 msgs

[Daniel Manrique]

> I have been painstakingly going through the lilo documentation.  I have not 
> found in the documentation, on my computer or at sunsite, a single reference 
> to this back door into my computer.  It is not even documented in the source 
> code.

then how is it that nearly everybody else knew about it? I'm sure I'm not
the only one who thought "oh, no, not the 'linux 1' security hole again"
when I saw your original post.

A quick search at red hat turned this out:

http://www.redhat.com/support/manuals/RHL-7-Manual/ref-guide/s1-sysadmin-rescue.html

Booting Single-User Mode Directly

You may be able to boot single-user mode directly. If your system boots,
but does not allow you to log in when it has completed booting, try
rebooting and specifying one of these options at the LILO boot prompt: 


 LILO boot: linux single
 LILO boot: linux emergency
           
In single-user mode, you computer boots to runlevel 1. Your local
filesystems will be mounted but your network will not be activated. You
get a
usable system maintenance shell. 

In emergency mode, you are booted into the most minimal environment
possible. The root filesystem will be mounted read-only and almost
nothing will be set up. The main advantage of this over linux single is
that your init files are not loaded. If init is corrupted or not working,
you
can still mount filesystems to recover data that could be lost during a
re-installation. 


> The fact we have a back door that allows root access that is undocumented is 
> something I would expect from M$ not linux.

The fact that you keep bashing Linux for this, which is nothing but a
MAINTENANCE FEATURE, makes me think whether you should really be using it 
at all.

> Why isn't this documented in an easy to find location?  That is very 
> troubling.  Especially since linux users scream bloody murder when back 
> doors are found in Windows.

It took me all but 30 seconds to go into red hat's web page, type "linux
single" at the search field, and come up with a buttload of matches
(actually about 9200 documents).

We scream bloody murder when *REMOTE* exploits are found in Windows. We
also scream bloody murder when they are found in Linux. A *REMOTE* exploit
allows you to gain access to a system without having an account there in
the first place. A *LOCAL* exploit will let you gain privileged access
when you have an unprivileged account. Those are unacceptable on any
operating system.

> If I wanted a computer OS that didn't need a password I would use Windows 
> 95.  One of the reasons for choosing linux was the security.  Right now 
> Win2000 looks like a better option.  The only way to boot this machine is 
> from the hard drive.  I am not so stupid as to forget root password, nor am 
> I pleased that the people writing this system appear to have set it up for 
> fools.

A lot of people are stupid enough to forget their root password. It has
happened to me too (yes, and bash me all you want, i'm as human and prone
to forgetting things as you).

What filesystem does Win2000 use? chances are it's NTFS. If that's the
case, it's as easy as booting with a Linux disk and NTFS filesystem
support (yes, i just checked and my 2.4.4 kernel does have NTFS support)
and I'll be able to scoop all the information I want from your
"unexploitable" Win2K system.

But hey, wait a minute!! I don't even need to be in the same room as a
Win2k computer to get all the files! all I need is for it to be on the
Internet and I can use one of many *remote* exploits available to gain
access to that system!! here is the difference between the kind of
security flaws we should worry about and the ones we shouldn't even be
rambling about, because they just are not what you have been claiming them
to be.

> If there is one undocumented back door there are many.
> Who are these back doors built in for?  Clearly not the users or there would 
> be documentation.

They are perfectly documented.


	- Roadmaster

----------------
*
Save a tree- use E-Mail!			roadmr at entropia.com.mx
*