>A normal user can do this, so this could be used for some kind of
>denial of service attack: system performance will be impaired and processes of
>other users may be killed. Hence the grave serverity.
Ehh..any user can run a process which uses any amount of memory
unless you use ulimit.
I agree this would be a bug in crypsetup, but calling it a user security
hole is not correct.
Fair enough
>To reproduce
>
> # produce a dummy file
> dd if=/dev/zero of=/tmp/foo bs=1k count=1024
>
> # try to run cryptsetup
> /sbin/cryptsetup luksOpen /tmp/foo /dev/mapper/_tmp_foo
The first argument after luksOpen should be a device, the second should
be a mapping name.
/tmp/foo is no device, it's a file.
/dev/mapper/_tmp_foo is no mapping name, it's a complete path.
The correct syntax would be something like:
/sbin/cryptsetup luksOpen /dev/something tmpfoo
I know the syntax to the cryptsetup command I gave is incorrect, but
crypt setup should catch such errors and print a useful warning
message rather than lock up the system
Furthermore, I can't reproduce this (using the version currently in unstable):
# dd if=/dev/zero of=/tmp/foo bs=1k count=1024
# losetup -f /tmp/foo
# crypsetup luksOpen /dev/loop0 tmpfoo
# Enter LUKS passphrase:
# /dev/loop0 is not a LUKS partition
# cryptsetup luksFormat /dev/loop0
WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
# cryptsetup luksOpen /dev/loop0 footmp
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
# ls -al /dev/mapper/footmp
brw-rw---- 1 root disk 254, 3 2006-12-14 19:14 /dev/mapper/footmp
# cryptsetup remove footmp
# losetup -d /dev/loop0
Yes, these commands work OK. I only discovered the bug when I made a
mistake in experimenting with cryptsetup
Regards
Rob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
