Brett Lymn wrote:
>
> According to Pavel Galynin:
> >
> >wrong statements I make here, we all had to learn at some point, you
> >weren't born clutching POSIX spec, were you?
>
> Some people have made that accusation ;-) Actually for my vintage it
> would probably have to be some K & R papers on their new idea for an
> operating system.
Hmm.. :))
>
> >> - typically on a unix machine (regardless of
> >> the architecture) you cannot take control of _any_ of the hardware, to
> >> do so would result in a access violation and the termination of your
> >> process.
> >NONE? No bugs, no tricks, nothin' ?
>
> Well, I have to admit you got me there. There was an exploit for the
> Sun sparc machines where you could do interesting things with a
> register window overflow trap (about the only case I can think of).
> These problems are very machine and os version specificTheoretically, if you could run some code on a specific platform, it
might be possible for it to determine at leas the processor ( I don't
know any machine language besides Intel's, so you'll have to excuse me
for incompetencies etc..
Say, on an Intel processor the first byte of code would do a jump to a
certain location where you would put the code to be executed if it was
determined that the code was running on Intel, but on Alpha, it would
just be a harmless register modification, but the next two bytes would
be Alpha's jump etc.
Actually, if you intend to only distinguish between two platforms, you
only need to make sure that Intel's or Alpha's ( for example, no
endorsement.. ) jmp wouldn't do anything bad on the other platform and
stick its code right after the jump:
Intel jump to label_intel ( It would be addition of
registers for Alpha )
Alpha code
end
label_intel: Intel code
Once you know the processor you may guess or detect an OS, then go about
finding its version...
> - the thing
> will not work without the right sort of circumstances. Very different
> to the situation with a pc running dos where all you need to do is get
> the program running to infect.
The only reason that this was the only one, I guess, is that most people
were looking for bugs that would allow them to get root access and not
get something executed, infected etc.
>
> >You just need to get the virus to execute, that's all. You can use
> >eploits and stuff like that the crackers use.
>
> Agreed - if you manage to get the virus to execute with sufficient
> privilege then you are hosed. Getting that privilege is not always
> easy and what works on one machine may fail totally on another.
>
> There have been cases where this sort of thing was tried - the morris
> internet worm springs to mind. The worm attempted to exploit some
> "well known" holes to gain access.
It wasn't a virus, after all, and it was rather lame...
>
> >
> >Just a simple question: New computers seem to come with flash bios, is
> >it possible for a user priviledged program to get to the hardware
> >necessary to reprogram it?
>
> I believe that you need to poke a magic i/o location to put the flash
> into program mode (I would hope so) in which case you should not be
> able to do this - access to the in* & out* instructions are restricted
> to ring 0 in protected mode (from memory again). Besides, from the
> boards I have seen you need to change a jumper to enable the program
> mode which is kinda hard to exploit via software ;-)
I was able to do that via the int 16h interrupt for AMI BIOS, because
they were smart enough to provide you an easy tool to f @
ck your
motherboard up so that you would buy a new one..
>
> >I've neither expertise, nor time to do so at this time. I have to learn
> >how to use Unix before programming for it.
> >
>
> Ummm for the purposes of the exercise you can just treat the kernel as
> a large protected mode program. Most of the stuff that sets up the
> processor for the kernel is in one file, locore.s on the machines I
> use.
OK, I'll look when I'll have time..
Paul.
References:
|
|
