F
Frederic Bonroy
Sol a écrit :
Yes, it's the same.
No, but it doesn't constitute infection either.
Yes, it's the same.
No, but it doesn't constitute infection either.
S
Sol
Frederic said:
Ah, now I get it. I misunderstood the original statement. You're
absolutely right, of course. If malware were to overwrite the system
BIOS it would effectively commit suicide since the only way to recover
from such damage is to reprogram the chip, thus overwriting the
malicious code.
Prost.
M
Mother's L'il Helper
David H. Lipman said:
.....does anybody understand the boot process anymore....???!!!, perhaps
only the "writers"...
....slow to get back to the thread....can't rightly say if the C008 or 5 was
the one...8 sticks in my mind for some reason....and just where are these
"rootkits" aimed at. I've gone back through the boot and still can't figure
out how anything can survive unless you let it in there.....seems to be
consistent with the "big three" BIOS software.
....help?!?
MLH
E
edgewalker
Sol said:
He's saying that the existance of ITW malware hiding in EEPROM is FUD.
This may be true as there is not much mention of it aside from the sources I
mentioned. The CIH payload was corruption of a program stored in EEPROM
and is not an example of malware hiding in EEPROM.
My answer still stands. If ITW existance is what you wanted to know about
then you asked the wrong question. As long as software accessible EEPROM
storage is large enough to contain malware, the possibility exists for mobile
malicious code to make use of it.
E
edgewalker
Addendum
Malware doesn't have to be mobile code. Malware could be "chipped".
Malware doesn't have to be mobile code. Malware could be "chipped".
S
Sol
edgewalker said:
To be perfectly honest, I didn't appreciate the difference between
infection of storage and destruction of data in storage until we came
to this part of the thread. I can see both points now, though.
Malware that infects ("hides in", "lives in", but doesn't necessarily
destroy or overwrite) EEPROM firmware (system or otherwise) certainly
could exist if there's unused space in EEPROM chips, just as you say.
I'll even be audacious enough to say that perhaps malware writers could
be sophisticated enough to modify code in EEPROM to enable their crap
to hide even in chips that lack unused space (perhaps by overwriting
"unnecessary" firmware code or by changing "necessary" code just
slightly enough so that, for example, the PC would be none the wiser
when it's directed to jmp GARBAGE instead of jmp POST =) -- again, I'm
just hypothesizing since, as I've said earlier in this thread, I don't
have enough deep technical understanding to say for sure what is or is
not possible as regards the subject at hand). However, by your own
admission,
So I don't need to be worried (at least at the moment) about the
existing malware slipping my BIOS a mickey. =)
In any event, I see now (and agree) that it is possible for malware to
infect (and has been proven capable of destroying the contents of)
EEPROM.
Many thanks for all this good information. The questions I asked in my
OP were more than answered.
K
kurt wismer
edgewalker said:
if i understand what you mean by 'chipped' malware, then securing
against it reduces to physical security... while it is certainly
important, it also tends to be the more intuitive side of security and
thus not so interesting a problem (physical security has millenia of
development behind it)...
R
Robert Baer
The registry is a good place to hide; it is such a garbage-can ofSol said:
crap to begin with...
A
Art
Portions of malware can reside in INI files as well, but they are all
on the hard drive which the OP excluded. Anyway, no malware can exist
entirely in such files since malwares are programs, and the registry
and INI files aren't programs.
Art
http://home.epix.net/~artnpeg
S
Sol
Art said:
Hmm... This's another point I'm not entirely clear on. So, if I were
to remove/disinfect all malware-infected data files (but not the
registry) on a hard disk, then are you saying that the infected
registry would be incapable (by itself) of executing any malicious
code? Or just less capable? Or are you saying something different?
Thanks in advance.
A
Art
Yes. Think of the registry as a repository of data Windows and
programs use. Think of malware as programs. They are entirely
different things. It really makes no sense to say malware resides
in the registry even though the registry might be used by the malware.
For example, a registry Run key might be set by malware to force
Windows to run the malware every time Windows starts. Is the
malware then "in the registry"? Not really. A portion of the malware
simply set a key in the registry. But the malware (program) is a
executeable file separate from the registry. You see?
Art
http://home.epix.net/~artnpeg
A
Art
Just a afterthought to my other response. The registry is sometimes
altered by malware in such a way that merely deleting the offending
program file(s) in not sufficient to clean up the PC. Malware might
leave a messy residue in the registry that screws up normal Windows
behaviour in a multitude of possible ways. So the registry then
requires either cleanup or restoration from backup. But none of
this means that malware actually resides in the registry ... just
undesirable payload effects of the malware. See the difference?
Art
http://home.epix.net/~artnpeg
E
edgewalker
kurt wismer said:
Yeah, I only mentioned it because I didn't mean to imply in my previous
post that malware = malicious mobile code, only that malware = malcious
software. Even though firmware and software aren't the same thing, the
difference between them is lessened by the ability to replace it from the
'write accessible by software' aspect of systems these days.
EEPROM flashing would easily be reduced to physical security with
the addition of a toggle switch - jumpers are far too technical and
dangerous for the average user evidently.
R
Robert Baer
I have written entire programs that existed in a DOS directory, andArt said:
in one of the FATs.
It takes less than 7 bytes of code to "reserrect" or execute code
hidden in a file. a picture (another kind of file), or the registry
(which is yet another file), or an INI file.
E
edgewalker
Sol said:
It is best to remain clear on the point that stored "programs" are infected
not the storage itself.
Corruption vs. Infection vs. modification? Maybe someone else can help.
I like to reserve 'infection' for viruses, but I see many articles refer to
'infection method' when trojans are being described. To me this is wrong,
basically "infection' is how the program attaches itself to the execution of
the host program and is reserved for viruses. I don't submit a better word
for using with trojans though, so who cares what I think!
More than that - there IS enough space ... and it IS accessible from software.
The code would be too specific to hardware to be anything widespread, even
CIH's payload failed to flash more often than not.
As for BIOS code...it tends to be very tightly written (no good compression
ratio to make more space like some viruses do) and very little "unnecesary"
code if any. However, there is unused space so that BIOS upgrades with
likely more lines of code can still fit.
No worries about malicious code being stored there in order to "hide"
or attach to code in the startup axis.
Destructive modification maybe, corruption, but not infection (virus)
or attachment to code (other). IIRC CIH wrote a memory dump
to the block device just to corrupt it. The 'possibility' of infection
exists remembering that the 'infected' program does not need to
also "hide" the malicious code - it can branch to it as long as it is
in (or can be put in) accessible address space.
It was a good question.
)
E
edgewalker
Art said:
Malware is software, software is a superset of programs. Program
control data and working data are a part of software. Malicious data
like a buffer overrun to crash a process is also malware.
E
edgewalker
Robert Baer said:
The code that resurrects data from elsewhere to run it as code is the
malware executable of note. Art's right about malware 'programs' not
entirely existing within those data files. But if malware were only about
programs, we would be calling them 'malgrams'.
)
A
Art
Semantics are wonderful aren't they?
You can't have "malicious"data without malicious code. In fact, it's actually quite silly IMO to
refer to data bytes as malicious. It's code that's (possibly)
malicious, not data.
Art
http://home.epix.net/~artnpeg
A
Art
Sure you can "resurrect" 'hidden code' as in steganography, for
example. But the picture image file itself is harmless enough. It
requires a companion executeable (program) to make use of such kinds
of hidden code. With no companion to make it work you have no malware
IMO. Or you could say that you have "potential" malware. But I prefer
to reserve the term malware for a fully functional piece of software
.... and not for its separate or isolated portions which, in
themselves, are harmless.
Art
http://home.epix.net/~artnpeg
E
edgewalker
Art said:Semantics are wonderful aren't they?
data without malicious code.
A malformed or crafted data input to a program intended only to crash the
program is still malware even if no code in included. Think 42.zip or just
about any buffer overrun that doesn't quite allow any attacker supplied
code to run. The overrun just corrupts memory and the program falls over.
Data can also be crafted to realize bad intent.