public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: snwahofm@mi.uni-erlangen.de, Jesse Pollard <jesse@cats-chateau.net>
Cc: Shawn Starr <spstarr@sh0n.net>, linux-kernel@vger.kernel.org
Subject: Re: Disturbing news..
Date: Wed, 28 Mar 2001 08:40:42 -0600 (CST)	[thread overview]
Message-ID: <200103281440.IAA48398@tomcat.admin.navo.hpc.mil> (raw)

> 
> 
> 
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
> 
> > >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.
> 
> And how exactly does this help?
> 
> fchmod (fd, 0666);
> fwrite (fd, ...);
> fchmod (fd, 0777);

By itself it doesn't - but if you also don't have user/group/world rw and
don't own the file, you can't do anything to it.

It's only there to reduce accidents. If you want to go full out,
remove the symbols from the file.

Now, if ELF were to be modified, I'd just add a segment checksum
for each segment, then put the checksum in the ELF header as well as
in the/a segment header just to make things harder. At exec time a checksum
verify could (expensive) be done on each segment. A reduced level could be
done only on the data segment or text segment. This would at least force
the virus to completly read the file to regenerate the checksum.

That change would even allow for signature checks of the checksum if the
signature was stored somewhere else (system binaries/setuid binaries...).
But only in a high risk environment. This could even be used for a scanner
to detect ANY change to binaries (and fast too - signature check of checksums
wouldn't require reading the entire file).

In any case, the problem is limited to one user, even if nothing is done.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

             reply	other threads:[~2001-03-28 14:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-28 14:40 Jesse Pollard [this message]
2001-03-28 15:08 ` Disturbing news Russell King
2001-03-29 12:05 ` Walter Hofmann
  -- strict thread matches above, loose matches on Subject: below --
2001-03-29 17:10 Jesse Pollard
2001-03-28 15:51 Jesse Pollard
2001-03-28 15:54 ` rmk
2001-03-28 21:19   ` Gerhard Mack
2001-03-28 15:43 Jesse Pollard
2001-03-28 15:31 Jesse Pollard
2001-03-28 14:43 Jesse Pollard
2001-03-28 14:15 Jesse Pollard
2001-03-28 14:53 ` Russell King
2001-03-28  5:52 Ideas for the oom problem Jonathan Morton
2001-03-28  6:16 ` Disturbing news Shawn Starr
2001-03-28  7:19   ` Matti Aarnio
2001-03-28  7:27     ` Shawn Starr
2001-03-28 12:08       ` Jesse Pollard
2001-03-28  5:50         ` Ben Ford
2001-03-28 12:50         ` Walter Hofmann
2001-03-28 14:04           ` Simon Williams
2001-03-28 15:04             ` Olivier Galibert
2001-03-28 15:49               ` Simon Williams
2001-03-28 11:57                 ` Ben Ford
2001-03-29  8:02                   ` Helge Hafting
2001-03-28 17:51                 ` Olivier Galibert
2001-03-28 12:53         ` Keith Owens
2001-03-28 13:00         ` Russell King
2001-03-28 14:10         ` Sean Hunter
2001-03-28 15:36           ` john slee
2001-03-28 16:18             ` Jonathan Lundell
2001-04-02 23:10         ` Dr. Kelsey Hudson
2001-03-28 17:29       ` Horst von Brand
2001-03-28 10:00   ` Helge Hafting
2001-03-28 13:25   ` Alexander Viro
2001-03-28 14:32     ` Romano Giannetti
2001-03-28 14:57       ` Bill Rugolsky Jr.
2001-03-28 14:57       ` Alexander Viro
2001-03-28 16:14         ` Romano Giannetti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200103281440.IAA48398@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=jesse@cats-chateau.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snwahofm@mi.uni-erlangen.de \
    --cc=spstarr@sh0n.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox