"~BD~" <~BD~@nomail.afraid.org> wrote in message
news:i9h9fd$cm9$1@news.eternal-september.org...
>
> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message
> news:i9fqng$ha0$1@news.eternal-september.org...
>> "~BD~" <~BD~@nomail.afraid.org> wrote in message
>> news:i9fdgi$16d$1@news.eternal-september.org...
> [....]
>>> He is a graduate of Manchester University and has a degree in
>>> Computer Science and Mathematics. He's worked for IBM since Dustin
>>> was born!
>>
>> That doesn't make him an expert on malware and/or its capabilities.
>
> Absolutely correct! He did understand all I mentioned to him though.
Did he argue with you? If not, I doubt that he understood completely.
)
>>> He confirmed that malware *can* infect the BIOS - and then reinfect
>>> a new or cleaned hard drive - *outside* of a laboratory environment.
How did the subject malware manage to store enough code in firmware to
achieve this? Did it displace or replace code that preexisted, or just
use available free space? How many storage areas were involved (EEPROM),
and how much total space was available.
>> I would like to know what he meant by that, but since he is not
>> here...
>
> He's a family man and still working - I doubt he's the time or
> inclination to play here! However, if you tell me *what* to ask him,
> I'll do so by email and advise you of his answer.
If firmware code was displaced to the drive (which is usually the case)
how would the malware recover from the error of not being able to find
this displaced and now *missing* code (and thus be persistent) when the
*new* drive is swapped in.?
>>> He did say that this was rare but he will liase with his specialist
>>> colleagues and thereafter endeavour to provide me with some
>>> information to confirm his assertion.
I think he misunderstood you, yet I think he is not confusing BIOS
*corruption* with persistent firmware infection.
>> He still hasn't said that any mobile code has shown that ability
>> (outside a laboratory).
>
> I don't think I recognise what you mean by 'mobile code' - do you mean
> 'in the wild'? Out there on the Internet?
Well, basically yes, but not limited to that.
When firmware storage chips became able to get updated code, they
technically entered the mobile code arena. Now that they are not only
updatable, but updatable by software running on the software platform
affected by that update, they entered into the mobile code *problem* -
and *that* is what I meant. The "in the wild" stuff usually means it has
risen above some population threshold - that is to say that it has
become enough of a *problem* for enough people that it must now be
addressed by the anti-malware community.
>> Even if he has actually seen for himself a persistant firmware
>> compromise (one that can re-establish itself fully on a *new* disk) -
>> he will still fail to convince anyone here that such can be
>> *installed* by malicious mobile code.
>
> Hey! He's a real life friend!
>
> Andrew is helping *me* understand matters - not trying to convince
> anyone on Usenet of *anything*!
Yes, but *you* are attempting to convince some here by relaying his RL
experiences. I was merely trying to point out that others have used
words (universal, general) that indicate to me that they are thinking of
a self-distributing persistent BIOS infection which is a near
impossibility if not an actual impossibility. Any discussion will be
worthless if the same words have us thinking about different things
completely.
>> In fact, I am probably the only one here that accepts that an
>> attacker with access to (and intimate knowledge of) a particular
>> computer can compromise firmware in such a way as to have a
>> *persistant* compromise of the machine even if the harddrive is
>> swapped out.
>>
>> ...and even then, such a machine would have to have a network
>> available for bootstrapping the malicious code.
>
> I'd like to know more about what you've said! Will you explain just
> where you have gained such insight?
Firmware EEPROM (collectively) may have just enough storage space to
accomodate a "beachhead" - not enough in and of itself to do battle. It
would need to do just enough to avail itself of code waiting on *other*
storage (such as on the disk or on the network) this is "bootstrapping".
> Is there anything in this Wiki article with which you disagree?
> http://en.wikipedia.org/wiki/BIOS
Probably not, but you may be misunderstanding something there - is there
something in particular that you would expect me or others here to
disagree with?
[...]
Reply With Quote