full-disclosure - Small (but useful) utility

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

From: andfarm at teknovis.com (Andrew Farmer)
Subject: Small (but useful) utility

On 5 Aug 2004, at 01:07, M.. Mohr wrote:
> When I couldn't find a decent file wiping utility on my own
> machine, I decided to write one.  Yes, I did search the net
> and came up with a few... but they seem to be poorly written
> and overly complicated.

shred(1)? It's in coreutils, for heavens' sake!

I'll take a look at this for educational purposes.


> You might want to name this program something inconspicuous
> (like 'index') and place it in /sbin, then add something like
> the following to rc.local:
>
> sleep 300 && screen -d -m find /home/foo -type f | xargs
> /sbin/index
>
> Just make sure to resume the screen as root within 5 minutes
> of system boot time :)

Er... kill the sleep within 5 minutes, maybe. And hope your
power never goes out unexpectedly (eep!) Not recommended if you
value your data.


As to the code, though...

1. writeout() doesn't deal with the "tail" of a file. Round the
    file size up to the nearest multiple of the file system's
    blocksize - probably 8K or so.

2. rand() isn't random enough for this. Use

3. Writing random bytes LAST is useless - the data can be read
    off the disk and "subtracted" from the signal to yield the
    previous level of data. If you're serious about wiping data,
    the best way to go with modern drives is to write several
    layers of random data.

    for x in 1 2 3; do dd if=/dev/urandom of=file; done

4. I don't know much about the buffering issues involved here,
    but you could at least run an fsync() after each pass to try
    to get the OS to write out each run of data.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040805/76761e90/PGP.bin