Where can they hide?

[Axel Hammerschmidt]

My question, simply put, is whether or not the true physical geometry
data (the LLF) that's stored on the disk can somehow be modified by or
infected with malware (or if the HDD's BIOS can be infected/etc.)
rendering the disk "uncleanable" (heh). My guess would be no, but I'm
paranoid about malware infection and I don't know enough about the
low-level operations of hard disks to know if what I'm asking is
possible or laughable or what. I understand that any high-level data
(malware or otherwise) can be dealt with by means of a (normal)
high-level format and partitioning, or by a disk wiping/zero-fill
utility like Darik's <sic?> Boot And Nuke. If it comes to that, I
mean.

There's reportedly (Ed Skoudis, Malware - Fighting Malicious Code) a
tool, RunEFS that can carve out a portion af an ext2 (UNIX) formatted
drive and label the associated blocks as bad by writing their block
numbers into the bad blocks inode. RunEFS does all this on the fly,
without reformatting the harddisk or corrupting data. An attacker kan
put data in those blocks and take data out of the fake bad blocks with
RunEFS.

 

[Art]

Maybe I put it there by editing the registry. It doesn't matter how it got there.

Aha! So you're the infamous edgewalker Trojan, eh?

Maybe, who knows!? The point is it's there. We are talking about this
hypothetical instance of malware not any previous or post instance that
may ir may not have had something to do with this one.

Well, Kurt claims its possible malware can exist in the registry.

The general run of worms and viruses are placed where they are as a result
of the previous iteration.

The initial install of worm code "places" its components. I dunno how
you can speak generally about "placement" of viruses. Most viruses
don't affect the registry.

Intitial instances of these might not have been.

Initial instances are placed by the infamous edgewalker worm!

This
hypothetical malware should be thought of as an intitial instance (like a seed)
which is 'still' malware even though it was not necessarily placed there by a
previous instance of the same or different malware.

The infamous edgewalker seed malware strikes again! You must be a busy
boy running around installing Trojans in users registries

Art

http://home.epix.net/~artnpeg

 

[edgewalker]

Aha! So you're the infamous edgewalker Trojan, eh?


Well, Kurt claims its possible malware can exist in the registry.


The initial install of worm code "places" its components. I dunno how
you can speak generally about "placement" of viruses. Most viruses
don't affect the registry.


Initial instances are placed by the infamous edgewalker worm!

By 'placement' I meant that the current item is there because of the
action taken by the previous iteration. By 'general run' I meant the
lineage after, but not including the intitial instance. A trojan batfile
that creates a com infector could be an intial instance of replicating
malware (but 'it' does not replicate) and yet itself might not have
been placed there by malware. The following generations of com
infection are indeed all placed by malware (the previous instance).

The infamous edgewalker seed malware strikes again! You must be a busy
boy running around installing Trojans in users registries

I'm not bored.

 

[edgewalker]

Weren't you talking in this instance about exploiting a vulnerability
in some av by multiply zipping a file many times? A multiply zipped
file, as such, is nether data nor code is it?

It's data - data that the unzipper program needs to convert the contents
back to its original uncompressed form. The center of the onion is the
original file which is also, I believe, not program code. It is data that
yields a very good compression ratio so that uncompressing it needs
lotsa space.

I dunno, what you're talking about. You had previously talked about
buffer overrun exploits and I say (said) it's the exploit code that's
the malware and not the chosen data pattern as you were claiming.
You don't do a buffer overrun exploit without exploit code do you?

Sure you do, if you only exploit the vulnerability to corrupt memory. If
you want to further leverage the overrun into executing code of your
choice then you of course will need to supply the payload code.

The flow to a subroutine may have to return back from whence it came (+1)
so that program execution can continue. It will drop a breadcrumb called a
return address pointer so it 'knows' where to return to. The buffer could be
used to contain data like a name from an input field. I put in my real name
(John Jacob Jingleheimer Schmidtt) and the program falls over. I examine
the contents of the buffer and find only John Jacob Jingleheimer Schmid and
find that the tt has stomped on the breadcrumb residing in adjacent memory.
This is where the exploit has worked, the machine is in a state to accept and
execute code supplied by me if I can only overrun the buffer with an address
that I control the contents of - no code is involved yet.

I input my name as John Jacob Jingleheimer Schmid[address of memory
I control] and the exploit is complete and still without code. I will need code
to place in the memory location now pointed to so that the runaway train
will have something interesting to crash into and execute. The exploit is
what diverts the train (without code) and any code that might follow is
payload. If this vulnerability were in a popular email client or server app
and I spammed the exploit out I could conceivably perform a DoS on a
large number of machines without doing any coding. I would call this
exploit "malware" even if the data is sent to only one victim, manually.