This patch doesn't look safe to me. mkfifo and mknod should not open
device files or fifos, since this has undesirable side effects in some
cases. For example, opening and then closing a tape drive might
rewind it.
As I wrote in April 2005, the original security issue is not a
vulnerability in
My kneejerk reaction is that it's not worth making this change. The
attack in question will work against almost any program that is
operated in an insecure directory, including the chmod program
itself. It'd be a real pain to work around this problem in all
applications, one at a time, and it's
Paul Eggert [EMAIL PROTECTED] wrote:
My kneejerk reaction is that it's not worth making this change. The
attack in question will work against almost any program that is
operated in an insecure directory, including the chmod program
itself. It'd be a real pain to work around this problem in
The problem of root executing things on demand for evil users cannot be
solved through technical means.
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Joey Hess [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.2.1-2
Severity: important
Tags: security
Our coreutils seems to be vulnerable to the problem described in
CAN-2005-1039.
http://www.securityfocus.com/archive/1/395489
A quick strace of mkdir -m 400 foo shows the problem:
Package: coreutils
Version: 5.2.1-2
Severity: important
Tags: security
Our coreutils seems to be vulnerable to the problem described in
CAN-2005-1039.
http://www.securityfocus.com/archive/1/395489
A quick strace of mkdir -m 400 foo shows the problem:
mkdir(foo, 0400) = 0
severity 304556 normal
thanks
At most this is normal, probably minor. The -m flag is basically
replacing a call to chmod, which has exactly the same problem. Any time
you fiddle with permissions or ownership in the filesystem you're
opening yourself up to this exact problem--and there's
Michael Stone wrote:
severity 304556 normal
thanks
At most this is normal, probably minor. The -m flag is basically
replacing a call to chmod, which has exactly the same problem. Any time
you fiddle with permissions or ownership in the filesystem you're
opening yourself up to this exact
On Wed, Apr 13, 2005 at 07:52:34PM -0400, Joey Hess wrote:
It's not really clear to me either why people consider this a security
hole now after not worrying about this class of problems for years.
Generally it means that someone just learned something that people
already knew about.
reason for it
Michael Stone wrote:
Generally it means that someone just learned something that people
already knew about.
I've never heard of this class of vulnerabilities, but I perhaps that
just makes me a clueless security noob.
Anyway, it was pointed out in a reply to the gzip bug that this kind of
hole
10 matches
Mail list logo
