Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120401140350.GA6856@openwall.com>
Date: Sun, 1 Apr 2012 18:03:50 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: hdparm update

Mesut, all -

I've just read the diffs between hdparm 9.35 and 9.39.  One observation
is that my recent change to our util-linux:

* Sat Feb 18 2012 Solar Designer <solar-at-owl.openwall.com> 2.11z-owl16
- Build and package %_sbindir/rdev also on x86_64 and non-x86 since part of its
functionality is not arch-specific and it is required by hdparm's wiper.sh.

is actually not needed for wiper.sh anymore (the script stopped using
rdev precisely because rdev was not always available).

Besides wiper.sh, there's raid1ext4trim.sh-1.4.  We could want to
package it as well, but probably as documentation (maybe include the
entire wiper/contrib/ directory in documentation).
wiper/contrib/README.contrib says that the script hasn't been tested by
the author of hdparm, so it may be more unsafe to include as an
immediately usable program.

The scripts under contrib/ fall under GPLv2, whereas hdparm itself is
under a "BSD-style" license (as it says).  We need to reflect this in
the License: tag in hdparm.spec.  We also need to package
wiper/GPLv2.txt e.g. as LICENSE.wiper.  Ditto for wiper/Changelog as
Changelog.wiper.  (We're already packaging the equivalent files for the
main hdparm.)

I reviewed wiper.sh for temporary file use.  It uses a predictable
filename, but luckily hdparm's fallocate.c uses O_EXCL.  So it would
seem that the only attack possible would be DoS against wiper.sh.
However, upon a closer look, I noticed that wiper.sh tries to check for
and remove the temporary file if it already exists.  This wouldn't fully
help against the DoS because there would be a race here, but this gets
funnier:  It uses "test -e" to check for the file.  What if we provide a
symlink instead?  If the symlink is dangling, then "test -e" does not
report that the filename is taken, so we have the DoS (and no need to
win a race).  If the symlink is pointing to something real, the symlink
is removed.  So someone who has privileges to create a file with name
that wiper.sh would use is able to check whether other files on the
system exist or not - even in directories that are -rx to the person.
Now, in practice this is normally a non-issue because wiper.sh would
likely be given a filesystem root directory and that would likely not be
writable to any untrusted user.  Yet we could want to patch this
(somewhat tricky to do in a way that would pass my review, so not a task
for Mesut currently).

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.