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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060908095307.GA8301@danisch.de>
Date: Fri, 8 Sep 2006 11:53:08 +0200
From: hadmut@...isch.de (Hadmut Danisch)
To: Roland Kuhn <rkuhn@....physik.tu-muenchen.de>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: Linux kernel source archive vulnerable


Hi Roland,

On Fri, Sep 08, 2006 at 11:16:35AM +0200, Roland Kuhn wrote:
> Hi Hadmut!
> 
> This is a FAQ, and a pretty lame one; see e.g. the first google hit  
> for 'linux kernel tarball permissions':
> 
> http://www.gatago.com/linux/kernel/6136874.html


1. If this is a known issue and it is *still* distributed in this way, 
   than this is not a lame FAQ, it is a matter of *extreme* ignorance.

   Ignoring such a security flaw just because it is a FAQ is not
   acceptable.

2. Telling someone to ask Google for this problem is pretty
   unlogical: It presumes that the user has already realized the
   permissions. In this case, why should the user still ask Google, if it
   just takes a chmod to fix the problem?

3. And in what way would asking Google achieve any improvement about
   this problem? This is a problem to be fixed at the tar generation
   side, not at the unpacking side.

4. The URL you gave it absolutely pointless. It just says that the
   permissions are they way they are. Your URL is exactly that kind of 
   useless answer that does not contain any information not already
   contained in the question. That way of science-by-google.

5. This is not about how to use tar. This is about security. Security
   is about closing security holes, not leaving them widely open
   because one could ask Google about how to circumvent them if you
   realized them.

6. It is unlogical to untar a source with a uid other than root if you
   need to compile, install, and run the program under root anyway. On
   the contrary: root's sources should be handled by root only and not
   by any other uid.


regards
Hadmut



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ