Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Microsoft Research: Strider GhostBuster Rootkit Detection and "...stealth software that hides in BIOS, Video card EEPROM"

Reply
Thread Tools

Microsoft Research: Strider GhostBuster Rootkit Detection and "...stealth software that hides in BIOS, Video card EEPROM"

 
 
Jim Byrd
Guest
Posts: n/a
 
      09-23-2005
Hi Roger - Just a small technical point to keep people from making wrong
assumptions. There are a number of different coding techniques, some useful
for varying degrees of error detection depending upon their redundancy such
as number of errors detected or errors runs of some specific length, and
there are others which can be used to generate syndromes which can be used
for error correction as well, the most commonly known probably being
Reed-Solomon codes. A CRC (as technically defined) is only an error
detection code, not an error correcting one.

--
Regards, Jim Byrd, MS-MVP
My Blog, Defending Your Machine, here:
http://defendingyourmachine.blogspot.com/

"Roger Wilco" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
> news:bEnYe.24103$fb6.9862@trnddc08...
>> From: "Roger Wilco" <(E-Mail Removed)>
>>
>>
>>>
>>> The BIOS routine runs on the processor almost without restriction
>>> (direct addressing, no protection) - there is no reason to assume all of
>>> the necessary code is in that location. The code could be fragmented and
>>> stored in multiple option ROM locations and stitched together for
>>> instance when shadowed.
>>>
>>> The bottom line is that what was once firmware has now entered the realm
>>> of (malicious) mobile code.
>>>

>>
>> It will fail CRC checks.

>
> Only if it has errors. Error in this context is a difference between the
> data the CRC's cyclic check sum was generated from and the new CRC
> cyclic check sum calculated from the data when received. How would a
> legitimate BIOS Upgrade reflash work if the checksum reference was
> inalterable? CRC's work because noise can't be expected to calculate new
> checksums, and they work better than simple parity checks for
> reliability and provide for error correction methods instead of only
> retransmission requests.



 
Reply With Quote
 
 
 
 
Steve Welsh
Guest
Posts: n/a
 
      09-23-2005
Why would it fail?

There is nothing magical about a CRC - it simply does a logical XOR
against a known polynomial. If someone is clever enough to inject
malicious code into BIOS, I would dareay that they are also clever
enough to make sure it passes CRC.

CRC is designed (and is very good at) detecting bit and burst errors
_in_transit_ - if someone deliberately manipulates the code of a BIOS
update ( whatever) to pass CRC, then it _will_ pass CRC, unless it is
corrupted en-route

Steve

David H. Lipman wrote:
> From: "Roger Wilco" <(E-Mail Removed)>
>
>
> |
> | Only if it has errors. Error in this context is a difference between the
> | data the CRC's cyclic check sum was generated from and the new CRC
> | cyclic check sum calculated from the data when received. How would a
> | legitimate BIOS Upgrade reflash work if the checksum reference was
> | inalterable? CRC's work because noise can't be expected to calculate new
> | checksums, and they work better than simple parity checks for
> | reliability and provide for error correction methods instead of only
> | retransmission requests.
> |
>
> If it comes from the factory (malicious or not) it will not fail a CRC check. IFF code could
> be appended to the BIOS routines maliciously it would fail a CRC check.
>

 
Reply With Quote
 
 
 
 
nemo_outis
Guest
Posts: n/a
 
      09-23-2005
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in
news:jZYYe.2631$SG3.1591@trnddc07:

> From: "Roger Wilco" <(E-Mail Removed)>
>
>
>|
>| Only if it has errors. Error in this context is a difference between
>| the data the CRC's cyclic check sum was generated from and the new
>| CRC cyclic check sum calculated from the data when received. How
>| would a legitimate BIOS Upgrade reflash work if the checksum
>| reference was inalterable? CRC's work because noise can't be expected
>| to calculate new checksums, and they work better than simple parity
>| checks for reliability and provide for error correction methods
>| instead of only retransmission requests.
>|
>
> If it comes from the factory (malicious or not) it will not fail a CRC
> check. IFF code could be appended to the BIOS routines maliciously it
> would fail a CRC check.
>



Not so. CRCs are an excellent protection against accidental code changes;
they're a ****-poor protection against intentional changes.

CRCs (despite being polynomials) have a linear structure. That is,
considered as a hash function it is simple to generate clashes/duplicates.
Given one CRC it is a trivial matter to generate a sequence that will
result in the same CRC. The modified code to be spliced in need only have
a few discretionary bytes (beyond its true "payload") somewhere before,
within, or after it, and voila: same CRC!

The industry should have chosen one-way hash functions (e.g., SHA family)
rather than CRC, but that's water under the bridge now.

Regards,

 
Reply With Quote
 
Roger Wilco
Guest
Posts: n/a
 
      09-24-2005

"Jim Byrd" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Roger - Just a small technical point to keep people from making

wrong
> assumptions. There are a number of different coding techniques, some

useful
> for varying degrees of error detection depending upon their redundancy

such
> as number of errors detected or errors runs of some specific length,

and
> there are others which can be used to generate syndromes which can be

used
> for error correction as well, the most commonly known probably being
> Reed-Solomon codes. A CRC (as technically defined) is only an error
> detection code, not an error correcting one.


Thanks Jim. I only meant that CRC is an improvement in reliability over
simple parity checks which in turn improves efficacy of any error
correction scheme they are applied to. Parity checks only detect odd
numbers of errors and are oblivious to even numbered errors and CRC is a
vast improvement over this - the main point I was trying to make was
that a correct CRC is not an indicator that data was not manipulated,
only that it was probably not manipulated by some dumb process such as
random bit switching or some transmission noise effect.


 
Reply With Quote
 
Jim Byrd
Guest
Posts: n/a
 
      09-24-2005
YW, Roger - Your point's well taken - I just didn't want people to be
mislead into thinking that a CRC could be used by itself for error
corrections.

--
Regards, Jim Byrd, MS-MVP
My Blog, Defending Your Machine, here:
http://defendingyourmachine.blogspot.com/

"Roger Wilco" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)
> "Jim Byrd" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Hi Roger - Just a small technical point to keep people from making wrong
>> assumptions. There are a number of different coding techniques, some

useful
>> for varying degrees of error detection depending upon their redundancy

such
>> as number of errors detected or errors runs of some specific length, and
>> there are others which can be used to generate syndromes which can be

used
>> for error correction as well, the most commonly known probably being
>> Reed-Solomon codes. A CRC (as technically defined) is only an error
>> detection code, not an error correcting one.

>
> Thanks Jim. I only meant that CRC is an improvement in reliability over
> simple parity checks which in turn improves efficacy of any error
> correction scheme they are applied to. Parity checks only detect odd
> numbers of errors and are oblivious to even numbered errors and CRC is a
> vast improvement over this - the main point I was trying to make was
> that a correct CRC is not an indicator that data was not manipulated,
> only that it was probably not manipulated by some dumb process such as
> random bit switching or some transmission noise effect.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
Any rootkit prevention, detection and/or repair suitable for use by the average user? Blue Event Horizon Computer Security 6 09-09-2006 12:23 AM
Any word on more Real Ghostbuster DVD's? Bratboy DVD Video 0 04-18-2006 05:04 PM
Rootkit detection and removal geermeister@gmail.com Computer Support 5 03-12-2006 03:36 AM
Microsoft Strider GhostBuster Rootkit Detection Software Download Pamela Fischer Computer Support 4 11-21-2005 02:21 PM



Advertisments