Hi. Its been an enourmous amount of downtime for Unix-Virus. Unix-Virus is
now being hosted by a faster, more stable server so hopefully this wont happen
again. To add more insult, in the change over the subscriber info was
deleted, so had to be recovered by dd'ing the disk. I think we got most people
back, but unfortunately its not perfect, so...

Anyway, onto the beef of the matter.. News.. I've written a new Linux ELF
Virus which brings the current virus technology to a new level.

* Generally a C virus
* Inline ASM when needed (NOT shellcode)
* No argv[0] references.
* Totally relocateable code
* Data Infection (any size virus) that is strip safe
* PLT 'execve' per process residency
* Chaining - No data segment entry points (uses original entry point)

This makes it probably the latest and greatest Linux virus seen to date, but
its still not as good as it could be. After I wrote this virus, some new
ideas came to mind that will TOTALLY revolutionize unix viruses. Mind you,
these are just ideas, I havent actually implemented the things I talk about
below, but I will shortly.

--
* Fully Resident Viruses from the User's POV
* Userland Stealth
--

Its possible to modify a process you own using ptrace under Linux so its possible to infect the PLT of running processes. This means we can infect such things as shells etc. This means that everytime we exec or open/close we can try to infect. Not just from the virus code, but anywhere your logged in, or running a process. Fully resident from the users pov. Imagine the success rate of something like this. you log in, you execute the virus. then in another shell your running you run some of your own code and b00m, you've infected your executeables.

Also, stealth is possible now.. ok, consider that 'stat' is used to gather file size information, we can hijack this family of functions via PLT infection and make it appear that our virus isnt present. Also, we can disinfect on open, and reinfect on close via the PLT. All this is in userland, so its not totally stealth, but its as good as were going to get without resorting to exploits etc.

Now, onto some tricky stuff... consider full residency

* virus gets run * infect the PLT of all processes

now.. Its not as easy as that to infect a process. why? because we dont have enough room in a process to copy the entire virus. In a process we generally have two options on where to copy code.

1) The ELF Headers at the start of the TEXT segment 2) The TEXT segment padding before the DATA segment

2) allows as more room to play with at the price of some extra work. 1) is easy and great for small code. Now, either way, were still too big for any decent infection. So, the idea is to bootstrap. Infect the process with code to load the real virus when the PLT code is run. How is this better? 'Brk' allows us to allocate memory on the fly which gives us a place to put our virus.

Now.. onto a dilema..

* virus gets run * infect the PLT of all processes

what hapens when a new process is spawned from a mechanism outside of the running processes inheritance etc? Well, it doesnt get infected.. a solution to this, is to scan for new processes in the hijacked PLT call.. But.. what happens when all our infected processes die and then a new login occurs. Our virus dies completely and is no longer resident. Now a possible solution is to have a background process running that scans for new processes. I dont particularly like this idea of having backgound processes. why? users or sysadmin's tend to notice long running processes. Naturally, we would use the RTM worm trick of respawning every few minutes, but still, its not particularly nice. If were having background processes run, then why not have one that searches for executeables. Again, I dont like the idea of having background processes... Anyway, this is a while down the track.

Feedback?

Silvio