Re: Disturbing news..

[Jesse Pollard]

On Wed, 28 Mar 2001, Shawn Starr wrote:
>Well, why can't the ELF loader module/kernel detect or have some sort of
>restriction on modifying other/ELF binaries including itself from changing
>the Entry point?
>
>There has to be a way stop this. WHY would anyone want to modify the entry
>point anyway? (there may be some reasons but I really dont know what).
>Even if it's user level, this cant affect files with root permissions
>(unless root is running them or suid).
>
>Any idea?

Sure - very simple. If the execute bit is set on a file, don't allow
ANY write to the file. This does modify the permission bits slightly
but I don't think it is an unreasonable thing to have.

>
>On Wed, 28 Mar 2001, Matti Aarnio wrote:
>
>> On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
>> > Date:	Wed, 28 Mar 2001 01:16:02 -0500 (EST)
>> > From:	Shawn Starr <[e-mail]>
>> > To:	<[e-mail]>
>> > Subject: Disturbing news..
>> >
>> > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
>> > Isn't it time to change the ELF format to stop this crap?
>> > Shawn.
>>
>> 	Why ?   "Double-click on attachment to run it" is typical
>> 		M$ client stupidity -- and the reason why there
>> 		are so many things that can mail themselves around.
>>
>> 	Changeing ELF-format would be comparable to what M$ did when
>> 	they met the first Word macro viruses -- they changed the
>> 	script language inside the Word...   What good did that do ?
>> 	Did it harm people ?  You bet...
>>
>>
>> 	You are downloading binaries off the net, and not compiling
>> 	from the sources ?  (Yes, we all do that.  This is why folks
>> 	these days carry PGP signatures at the RPM packages.)
>>
>>
>> 	So, the program modifies ELF format executables by rewriting
>> 	some instructions in the beginning (propably to map-in the virus
>> 	code proper with X-bit on), and tags itself (PIC presumably) at
>> 	the end of the file.
>>
>>
>>
>> 	Another issue is "safe conduct" practice of installing binaries
>> 	with minimum privileges (ok, granted that for e.g. RPMs that
>> 	usually means root), and *never* running them with undue levels
>> 	of privileges -- not even as the owner of said executables.
>>
>>
>>
>> 	Ok, granted that we have dangers of getting arbitrary BAD programs
>> 	into our systems, how can we combat that ?   Virus-scanners
>> 	(as much good as they could do..) don't really work in UNIX
>> 	environments where "small things" like intercept of every
>> 	exec(), and open() via privileged program (scanner) is not
>> 	available feature. (I think doing it by passing a AF_UNIX
>> 	message with fd + flags to registered server, expecting answer
>> 	for the open() -- this would happen *after* the file open is
>> 	done with user privileges, but before the call returns.)
>> 	(Trapping open() so that shared-libraries could be scanned.)
>>
>> 	There could be, I think, a method for doing such intercepts,
>> 	which could be used by security scanners to implement some
>> 	sense of security in Linux-like systems.
>>
>> 	Is it good enough, e.g. when some file is multiply-mapped to
>> 	shared programs, and application rewrites parts of the file ?
>> 	Can it detect that kind of multi-mapped writing-sharing ?
>>
>> 	Can such system be made fast ?  (Scanner becomes performance
>> 	bottle-neck.)
>>
>>
>> 	How about PROPER Orange Book B-level security ?
>> 	E.g. NSA trusted-linux ?
>>
>>
>> /Matti Aarnio
>>
>>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [e-mail]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [e-mail]

Any opinions expressed are solely my own.