Security Incidents: Re: cron exploit?

[Barry Fitzgerald <bkfsec () sdf lonestar org>]

It's a good idea to mount /home (or wherever you put your home 
directories) with the same options as well.  For the exact same reason.
Rule of thumb: anything that the user doesn't need to write to, mount as 
ro and only take it out of ro if necessary, mount all other 
write-required locations as nodev,nosuid,noexec...
Sure, there are ways around this - but it makes getting an exploit and 
running it on the system a heck of a lot more difficult, so all those 
nice little local buffer and heap overflows (and other potential 
privilege escalation ilk) are less dangerous than they would otherwise be.
      -Barry


Vinicius Moreira Mello wrote:

> Jeremy,
>
>     May be it exploits an improper tmp file created by an application run
> by root or an improper file permission that you haven't noticed.
> Something I always do in systems that users log into is mounting
> /tmp,/var with nodev,nosuid,noexec permissions, removing the compiler
> and unsetting the suid bit of many executables, including crontab.
>
> Gook luck,
>
> --
> Vinicius
>
> Jeremy Hanmer wrote:
> > Unfortunately, the permissions were all fine.  The user apparently 
> poked
> > around cron.daily, but there isn't any evidence that they were ever 
> able
> > to successfully modify anything in there.  All files (and the directory
> > itself) were owned by root.root, and all were 755.  The *only* file
> > found modified by tripwire was /sbin/init.  Nothing else in any library
> > paths, bin paths, or /etc had been touched.
> >
>
>
> --------------------------------------------------------------------------- 
>
> ---------------------------------------------------------------------------- 


---------------------------------------------------------------------------
----------------------------------------------------------------------------