linux-kernel - Re: ext3 hacked filesystem (by debian exim4 exploit) available for analysis and bugreporting

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: <20110729213156.GA32685@citd.de>
Date:	Fri, 29 Jul 2011 23:31:56 +0200
From:	Matthias Schniedermeyer <ms@...d.de>
To:	Pavel Machek <pavel@....cz>
Cc:	Luke Kenneth Casson Leighton <lkcl@...l.net>,
	linux-kernel@...r.kernel.org
Subject: Re: ext3 hacked filesystem (by debian exim4 exploit) available for
 analysis and bugreporting

On 29.07.2011 21:59, Pavel Machek wrote:
> On Mon 2011-07-25 22:08:24, Luke Kenneth Casson Leighton wrote:
> > On Mon, Jul 25, 2011 at 2:45 PM, Matthias Schniedermeyer <ms@...d.de> wrote:
> > > On 25.07.2011 13:08, Luke Kenneth Casson Leighton wrote:
> > >> folks, hi,
> > >>
> > >> apart from anything, files which cannot be deleted (and cannot be
> > >> detected as "corrupted" by fsck.ext3) is pretty damn serious.
> > >
> > > You did try lsattr and checked that the files aren't 'immutable'?
> > 
> >  i didn't! :)  didn't know about (but should have guessed) ext3
> > attributes.  they are indeed - thank you matthias.
> > 
> > root@...etbaby:/mnt/horsebox/tmp3# lsattr *
> > ----ia------------- bin3/kill
> > ----ia------------- bin3/ps
> > ----ia------------- c.pl
> > ----ia------------- e.conf
> > ----ia------------- sbin3/sysctl
> > ----ia------------- usrbin3/uptime
> > ----ia------------- usrbin3/tload
> > ----ia------------- usrbin3/free
> > ----ia------------- usrbin3/top
> > ----ia------------- usrbin3/vmstat
> > ----ia------------- usrbin3/watch
> > ----ia------------- usrbin3/skill
> > ----ia------------- usrbin3/pmap
> > ----ia------------- usrbin3/pgrep
> > ----ia------------- usrbin3/slabtop
> > ----ia------------- usrbin3/pwdx
> > ----ia------------- usrbin3/snice
> > ----ia------------- usrbin3/pkill
> > ----ia------------- usrbin3/w
> > 
> > so - looks like it's not as bad as i thought.
> 
> Should ls -l be moddified to show something when file has immutable
> (and friends) set?

AFAICT lsattr, in e2fsprogs, only does a 'stat'(lib/e2p/fgetflags.c) and 
checks st_flags, which i can't see in the "man 2 stat"-man-page i have 
installed, but nonetheless that is what it appears to do.

So assuming there are no incompatibilites between filesystems, the 
information appears to come "free" with the stat(s) that ls has to do 
anyway. (In the sense that there doesn't appear to any excessive 
overhead involved, especially no additional I/O).

So i would say: definitly.




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/