kam.leo at gmail.com
Sun Dec 11 07:09:13 UTC 2005
On 12/10/05, Jeff Vian <jvian10 at charter.net> wrote:
> On Sat, 2005-12-10 at 21:59 -0800, Kam Leo wrote:
> > On 12/10/05, Scot L. Harris <webid at cfl.rr.com> wrote:
> > > On Sun, 2005-12-11 at 00:45, Gene Heskett wrote:
> > > > On Sunday 11 December 2005 00:35, Craig White wrote:
> > > > >On Sun, 2005-12-11 at 00:31 -0500, Gene Heskett wrote:
> > >
> > > > I forgot to mention that all the unpacked files are in his sons name,
> > > > an unpriviledged user, but with a very weak password. So we think it
> > > > came in and was running as this user. His son, taking comp sci
> > > > courses as a junior in college now, simply would never have done this,
> > > > its just not his style. All he ever uses is email & a web browser.
> > >
> > > Sounds like a guessed password then. Regardless, the best thing to do
> > > is to rebuild from scratch and then set strong passwords on all
> > > accounts. That is the only way to be sure the system is really back
> > > under your control.
> > >
> > Isn't rebuilding a little extreme? If the cracker got into an
> > unpriviledged user's account and no further isn't that particular user
> > account the only thing at risk? Shouldn't changing all passwords to
> > strong ones and deleting the infected user account and files be
> > sufficient?
> Not at all extreme.
> There is no certain way to identify exactly what was done and what may
> have been compromised.
> Suppose something has actually been compromised and is not totally
> removed. Then just when you think it is all fixed you now find that you
> are leaking lots of private/confidential stuff out to somewhere.
This works only if you have total control of what gets installed on a
system. If you are in a development environment where users have the
capability of installing their own applicaions in their home directory
how do you determine what is legitimate and bogus?
> Besides, the password cracker is enough to confirm that no current
> passwords and no existing account is 100% secure.
No password protected account ever is secure.
> Reload and be safe, or try to fix anything that may have been
> compromised and wonder if you got it all forever.
Will not stop this exploit. There is no 100% shield against
unauthorized use of password protected accounts.
More information about the fedora-list