U-Zip 1.1 (white-hat :) README
==============================

0.
--

This program can be used to do something bad/cause errors/crashing systems.
IF YOU WANT TO DO SUCH THINGS GO AWAY!
If not, read on but always remember that you have to use this program with brain!


1. Introduction
---------------

As you maybe know, i published recently an ext2-fs exploit
for linux 2.0.x kernels that allowed you to hide some data
in files.
In short i can say: 'Here's da UFS version'.

2. Some internals
-----------------

As with E2-Zip i provide 2 new library-functions to you:

    o ufs_hide_file(...)
    o ufs_fetch_file(...)
    
they are similar to E2-Zip. If you don't know what i'm talking
about, please read the whitepaper about ext2 available at
    http://www.kalug.lug.net/stealth
.
To be precise, the functions are not the same, since you have to
specify the mountpoint in ufs_hide_file() too, since the
hot-remount works now, so you don't need longer to
unmount/mount the filesystem as with E2-Zip.
The way the functions doing their work is the same as on E2-Zip,
so i would refer to this again.
Since we have no UFS-library as with ext2, i went another way:
as you all know, fsck (sometimes called fuck :)  uses its own
functions to acess the filesystem. So we use it too. Althought
it is not very difficult to use these functions, i spend a whole
weekend to understand how to use these 'library'.

3. The unbelieveable: bypassing securelevel 1
---------------------------------------------

3.1. What are securelevels ?
----------------------------

4.4 BSD introduced securelevels and file-flags to make the OS
much more secure. You can set special flags on files, 'schg' for example,
which will prevent an attacker from deleting/modifieing this file.
(NOTE that filefalgs are not the same as filemodes; you also have
to have the permissions to modify the file ofcoze, regardless of the
fileflags)
This ofcoze will only work if you set the securelevel > 0:

    [stealth@core]# sysctl -w kern.securelevel=1
    kern.securelevel: -1 -> 1
    
There are 4 securelevels:

    o -1: permanently insecure level. Fileflags are useless.
    o  0: from the secure-point the same as level 0
    o  1: interesting. Fileflags works now. So if you do
    
          [stealth@core]# chflags schg /usr/bin/login
	  
	  you won't be able to modify this file. As you might can
	  imagine this is very powerfull.
	  To delete /usr/bin/login you have to boot in single-user mode    
	  and then doing your work. Attackers don't have access to this
	  mode, so it's hard. You are also disallowed to:
	  
	      + writing to /dev/mem and /dev/kmem
	      + loading kernel-modules
	      + writing directly to mounted disks
	      + tracing init and forcing it to draw back
	        securelevel (init is the only process who can do it)
	      + playing with /proc
	   
	   Whoa! All the kewl things that can be done with computers
	   are forbidden! But even then: We will break it! Read on...
    o  2: Heavy secure mode. You can do really nothing, even writing
          to unmounted disks. I don't know if someone ever broke this,
	  except due to some stupidity of the admin.

3.2 Inverting the Matrix ;-) Or: breaking level 1
-------------------------------------------------

If you have read the above lines properly, you propably
noticed that in level 1 you are not allowed to write to
MOUNTED disks. Hah! Thats it! We'll unmount the disks and
clean the flags via direct file-access. Thats easy and
good. I hear you screm: 'Hey, i can't unmount the root-filesystem!'
Right. But on most BSD-systems you will have a very small amount of
space on / directly, instead you have an own partition for /usr,/var and
propably /etc. The BSD-distri even forces you to do so. Since login
resides in /usr/bin you will be able to free login from its flags.
So a new fucntion is born:

    o ufs_clean_flags(const char *filename, const char *mp, const char *fs)
    
where 'mp' is the mountpoint where 'fs' is mounted on. Remember that
the device (fs) is one of /dev/rfd0, /dev/rda0s1 (my zip-drive) and so
on, so you have somewhere a 'r' in it. If you simply use /dev/fd0 instead
you will get BUSY-errors.
ufs_clean_flags() will stat() the requested file - obtaining the inodenumber.
It then unmount's the mountpoint and modifies the fileflag that
is part of the inode to be 0. It writes back the result and re-mounts the
device back to mountpoint.
ufs_cleanflags() works only in securelevel 1! I haven't had a deeper look
at level 2...
Say, for example you want to clean /usr/bin/login from the IMMUTABLE flag (schg), so
you can replace it. Since almost all BSD-systems have own partition for /usr, you
type
	# uzip -F /dev/rwd0s1f -M /usr -c /usr/bin/login
	
ATTENTION: UZip directly access the filesystem, so you may can fuck up your whole
           system and loose ALL data!!! If you want simply play around with this piece,
	   please, please, please use a floppy-disk!
	   
It is possible that you cant unmount /usr since someone is executing a program
there, so it's up to you to either:
	
	o unmount it by hand via '-f' and remount it, or
	o set FORCE_OR_NOT in ufs.c to 1. this will have the same result, but
	  will propably cause some errors in the filesystem. However, it
	  works if you do so, i tested it with /var/log/messages.
	 
UZip 1.1 also trys to restore the access and modification time (E-Zip doesn't).


3.3. Avoiding detection
-----------------------

Well, if someone runs runs fsck over the partition, he will see what you have done.
It is AFAIK not possible on (non-swap) partitions to be undetectable with such things.
This is the nature of FS-modifieng tools. NOTE that you produce some inconsistency in
the current filesystem if you run UZip!
However, UZip is smart enough to set the CLEAN-flag in the current filesystem thus avoiding
detection at bootup by fsck.
Smart sysops should run fsck manually.

4. Install
----------

There's not much to do. You need the sources of fsck installed,
the best is in /usr/src/sbin/fsck (if not there, edit the makefile)
since we link U-Zip against fsck-library.


5. Bugs
-------

Sometimes, you will loose your data in the corrupted file. I don't know how can this happen,
but i tested a lot of binarys and stored them somewhere in other bin's on HDD/Zip/floppy
and after fetching it all was OK. But sometimes...
It's strongly recommented to use executable/binary files for storing data. Please read
ext2-whitepaper if you want to know why.

6. References
-------------

    [1] UNIX Systems Programming for SVR4 -- O'Reilly
    [2] Design and Implementation of the 4.4BSD OS -- Addison Wesley
    [3] fsck and fsdb sources


Good luck,
-- Stealth.
