Re: Lets make sure these are fixed (was: Tim Newsham)

[newsham () wiliki eng hawaii edu (Timothy Newsham)]

> His explanation was plausable, and nobody with one working neuron would
> post that stuff from his own account.  Remember, if a .forward file was
> placed in his home subdir (and it would go unnoticed), one could simply
> mail this stuff to him, and it would be passed right on.

There was a .forward placed in the account but the files were mailed
directly from the account.  I believe the forward was placed there
either to see what kind of replies I was getting or to cause a mailing
loop.

> Unless they have a way to trace back and catch this clown (not the victim
> whose account was compromised - wonder who else's account has been
> compromised on the same site?) huffing and puffing serves no purpose.
> Better to stay non-commital for the moment, and get evidence, and CATCH
> these people that are breaking into systems and introduce them to the
> criminal justice system rather than drive them further underground.  If
> source access were not limited to a privileged few (and the crackers,
> of course), these problems could be addressed MUCH better - think of
> the wealth of talent to deal with this out there, being ignored because
> of denial of resources!!!

The attacker compromised the root account on the system.  He was
mainly after me as far as I can tell and probably doesnt care about
other accounts on the system.  This is all unofficial, I am not an
admin at the site in question.

> Question I have is - how does doing all those saves and restores in
> SPARC assembler result in the user being able to modify the ucred struct
> in a running program without privs to modify memory directly?  I suppose
> a workaround would be to (cringe) disable ps temporarily, or forthose
> who can, modify it to not show that address info and and deny the info
> needed to find the ucred struct in a running program, at least until a
> real fix is devised.  Perhaps another idea would be to devise some test
> to result in the process being killed when a user overflows the register
> windows (hell, I'm really groping here, so bear with me).

There was an error in the frame pointer overflow trap handler (so I'm
told).  That script that was posted is not operational (it was not
written by me).  I'm told there is an instruction missing or something
like that.

> One thing is obvious:  The crackers have access to source and time to
> really study it, most admins DON'T.  They also know their way around in
> SPARC assembler (I am still looking for a good book on the subject).

I doubt most hackers know there way around sparc assembly.  More likely
a few hackers know how to steal programs written by people who have
found a defect in the kernel and have written an exploit to test it.

> These odds need to be evened up a bit.  And if vendors knew about this
> kind of vulnerability and did or said nothing, that borders on criminal.

I believe sun knew about this hole, but what can they do immediately?
Not much.  Announcing the fact that there is a kernel bug doesnt help
much because next to no one would be able to fix it (including most
people who have source).  

> pat@rwing  [If all fails, try:  rwing!pat () eskimo com]  Pat Myrto - Seattle WA
> "No one has the right to destroy another person's belief by demanding
> empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
> and Director at Handgun Control Inc.

Cheers.