full-disclosure - Re: Linux kernel source archive vulnerable

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]

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/