Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Protecting the Operating System

Reply
Thread Tools

Protecting the Operating System

 
 
Nomen Nescio
Guest
Posts: n/a
 
      09-28-2006
Sebastian Gottschalk wrote:

> > Regarding point 1, it takes a fair level of technical skill to write one's
> > own MBR to splice into the chain.

>
> No, it's trivial.


Let's just assume for a second that your fantasy bears some small
resemblance to reality, and you're really not just a bag of wind. If
it's "trivial" to code and install a custom MBR, then it's an order of
magnitude more trivial to simply replace it with a good one. Your
"threat" is so easily countered it's pointless and insignificant.

That obvious fact aside, have you ever actually tried replacing
bootstrap code on an encrypted drive, or are you talking out your ass
as usual? Would you be real shocked to find out that there's no
mainstream whole disk encryption software available today that doesn't
do a considerable amount of integrity- and self-testing? Doesn't take
great pains to safeguard what little there is left out in the open.

I suggest you actually *try* your hair brained theory before you make
yourself look any more foolish. You're in for a rude awakening.

> > Moreover, unless the modified MBR can do
> > wnhat it wishes *as well as return control to the original encrypted boot
> > process* all within one track, then it will have to put its malware
> > elsewhere on the HD.

>
> You just need one little modification of the original boot program, that is
> to store the entered password or the derived key somewhere. Just due to the
> 512 Byte alignment, you usually already have enough space available. And
> what about optimizing the original program to reduce its size? Trivial.


Riiiiiight.... that's why boot sector viruses are still so prevalent
today. Because it's so much more easy to hide things in an MBR than
poke holes in networking protocols and software. That's why boot sector
viruses were never detected or anything, huh?

Idiot.

 
Reply With Quote
 
 
 
 
Ricardo
Guest
Posts: n/a
 
      09-28-2006
Użytkownik "nemo_outis" <(E-Mail Removed)> napisał w wiadomości
news:Xns984C683A9DC0abcxyzcom@127.0.0.1...
>> ...

> Which is why instead I would suggest using a fully-encrypted drive and
> only having to check (or as I describe above, simply overwrite) the only
> tiny unprotected part, the MBR and Track 0.

Thanks again for your kind explanation. You suggest to backup MBR and Track
0 which as I recon the first sector of the active partition, right. Let's
assume that I have my WinXP on the first partition of my HD and it has the
assigned letter of C. Now to make the backup from a bootable Small Linux CD
I would have to use the following command:
"dd if=/dev/hda bs=512 count=1 of=/path/to/removable/media" -> to copy HD
MBR
and
"dd if=/dev/hda0 bs=512 count=1 of=/path/to/removable/media" -> to copy
bootstrap of the active partition
Is that correct?
Thanks in advance for your help.
Regards,
Ricardo


 
Reply With Quote
 
 
 
 
Vanguard
Guest
Posts: n/a
 
      09-29-2006
"Borked Pseudo Mailed" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) d.net...
> Sebastian Gottschalk wrote:
>
>> No, you really don't get it.

>
> Don't think so? Here's how the OP started this thread...
>
> "I have just come to the conclusion that the only way to protect the
> machine with free physical access is..."
>
> If you're having trouble with the meaning of "free physical access"
> bitch at whatever third world educational system it was that let you
> remain functionally illiterate, and spend half your monthly
> McDonald's
> wages on a pocket dictionary.
>
> Is that clear enough for ya' there skippy?
>
> <snip juvenile reiteration of the obvious, but irrelevant>
>



God forbid the OP just gets a padlock to secure the case and use BIOS
password. Would be pretty obvious upon return when the case was
smashed apart. You could use lock-down plates (to prevent the case
from walking off) and disk locks (where the plate goes over all
externally accessible drives to prevent their use providing you even
bothered to provide them). If they can't take it or get inside, they
can't modify the BIOS settings to disable the password, to reenable
the disabled IDE ports to those CD/DVD drives or floppy, or reenable
the disables USB, firewire, eSATA, COM, or other ports.

You don't even have to provide physical access to the system unit.
Put it away where it is physically secure and let the users only get
to the keyboard, mouse, and monitor. The drives are all locked up
along with the case. Those users would still have free physical
access to the I/O devices that they need and not to everything else.
Just how to physically protect the computer depends on WHAT type of
computer you are asking about. The OP merely said "the machine".
Well, that doesn't say if it's a laptop, desktop, rackmount, or what.


 
Reply With Quote
 
Vanguard
Guest
Posts: n/a
 
      09-29-2006
"nemo_outis" <(E-Mail Removed)> wrote in message
news:Xns984C53303B13Babcxyzcom@127.0.0.1...
>> Yes, bootstrap programs can be moved to alternate locations and
>> another bootstrap program ran FIRST which then chains to the
>> wherever
>> the original one got moved. The MBR is not protected if physical
>> access is not protected.

>
> Yes, this can be done, but:
>
> 1. it is not quite as straightforward as you make out
>
> 2. it is easily thwarted.
>
> Regarding point 1, it takes a fair level of technical skill to write
> one's
> own MBR to splice into the chain. Moreover, unless the modified MBR
> can do
> wnhat it wishes *as well as return control to the original encrypted
> boot
> process* all within one track, then it will have to put its malware
> elsewhere on the HD. And there our malefactor has a bit of a
> problem:
> there's no place to put it without risking trashing some encrypted
> file on
> the HD (Yes, the malefactor can just "roll the dice" that he will
> not trash
> a file, not trash an important file, or the mess will not be
> noticed, but
> that is hardly an - ahem! - elegant solution.
>
> Regarding point 2, it is very easy to boot up from, say, a known
> good read-
> only CD and verify the MBR (or even just overwrite it). Then one
> would boot
> again, this time from the encrypted HD.
>
> Much easier and faster than verifying the state of the entire HD.
> This
> two-stage boot is seldom done, I agree, but that's because the risk
> of MBR
> tampering is largely a theoretical one that is strongly discounted
> in most
> folks' threat model.
>
> Regards,
>



The MBR is the first sector on the hard drive. In there you get 446
bytes for your bootstrap code. Rather than have it load a program
that is stored within a partition, use the first track which isn't
accessible to any partition. Several boot managers work this way by
putting the rest of their program in the unused first track. 64
sectors/track X 512 bytes/sector = 32KB. Remember that the *normal*
MBR bootstrap program reads the partition table (also in the MBR) to
find which partition to boot from. That doesn't preclude having the
custom MBR program boot from some other device which can still read
the partition table in the normal MBR (or you copied the entire MBR
with bootstrap area and partition table).

Boot managers have long been able to boot to partitions on other
drives than the first physical one discovered by the BIOS. Since you
are not restricting physical access to the computer, I can install my
own hard drive inside. For a laptop (or desktop), you could clone
(using a physical sector copy and not one that needs to read into the
file system which is more a "logical" image) the owner's drive to your
*bigger* drive so their partitions don't occupy all the drive's space
and you'll have LOTS of space to do your nasty stuff. I doubt the
BIOS does much more than behave as a loader to put the normal
bootstrap program into memory and pass control to it, and you could do
that with the huge nasty stuff you put on the unused area of the
larger hard drive.

The BIOS loads your custom MBR bootstrap program and passes control to
it. Your custom bootstrap program then loads your bigger program(s)
from your part of the larger hard drive. Your part of the hard drive
wouldn't even be in the partition table to be discovered there. The
partition table is read by the standard bootstrap program to find the
starting sector for the active partition but your custom bootstrap
program will already have that info. Your custom bootstrap program
then loads your nastyware. With 32KB for the possible size of the MBR
bootstrap area and 1st unused track, it could even scan for your
nastyware in the unused portion of the hard drive. Your nastyware
then loads the original bootstrap program that you copied out of the
MBR but under the envelope of its control.

Presumably your security product that is encrypting the drive and
using its own bootstrap program to provide the other half of the key
should provide a means of saving a backup of the MBR or allow you to
regenerate it (using information only known to you or by having a cert
saved to other media). So the above scenario would be thwarted by
simply restoring the "good" MBR bootstrap area but that would require
the user to know something was awry to know they needed to restore.
However, I just brough up one scenario and am not going to spend
months figuring out others. If DriveCrypt was worthwhile as a
business solution, perhaps it stores a hash or image of its bootstrap
program within the encrypted volume so it can verify it the bootstrap
program that is currently in the MBR is its own rather than some
nastyware substitute. Simply relying upon the inability to decrypt
because the MBR bootstrap area got written with another program is not
sufficient security. You need something like a 2-way view: the MBR
bootstrap, if theirs, will only decrypt those volumes for which it was
keyed for and the loader (that should get started BEFORE loading the
OS) should look back at the *physical* MBR to determine it was its
bootstrap program and that it wasn't executed from somewhere else.
The good MBR bootstrap program would be needed (somewhere) to access
the encrypted volume while the boot program that gets loaded from that
encrypted volume does a system integrity check to ensure its boot
loader is in the physical MBR so it was probably the one used to
access the encrypted volume. Of course, the nastyware could load its
copy of the original bootstrap program (for the security product) into
memory, copy the original bootstrap program back into the physical
MBR, and then pass control to the memory copy of the original
bootstrap program. This makes it the nastyware less hardy as it has
only one shot at capturing the login credentials but once is probably
enough.

If you're not going to physically restrict access to the guts of the
computer, you can't protect it from being modified. The MBR is a weak
spot for the whole-drive encryption products. So far, all I've seen
are users saying that it is not likely. What I haven't heard is
details stipulating how these products protect their MBR bootstrap
programs. Such vulnerabilities are not something the security vendors
want to discuss in public.

 
Reply With Quote
 
TwistyCreek
Guest
Posts: n/a
 
      09-29-2006
Vanguard wrote:

> God forbid the OP just gets a padlock ...


<snip>

Please feel free to take as much time as you need to go back and read
what the OP plainly stated in his first post. We're happy to wait for
slower readers here.

 
Reply With Quote
 
Vanguard
Guest
Posts: n/a
 
      09-30-2006
"TwistyCreek" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Vanguard wrote:
>
>> God forbid the OP just gets a padlock ...

>
> <snip>
>
> Please feel free to take as much time as you need to go back and
> read
> what the OP plainly stated in his first post. We're happy to wait
> for
> slower readers here.
>



Stop smoking those mushrooms. The OP never addressed physically
securing his computer while still allowing free access to it.

 
Reply With Quote
 
Nomen Nescio
Guest
Posts: n/a
 
      09-30-2006
Vanguard wrote:

> "TwistyCreek" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Vanguard wrote:
> >
> >> God forbid the OP just gets a padlock ...

> >
> > <snip>
> >
> > Please feel free to take as much time as you need to go back and
> > read
> > what the OP plainly stated in his first post. We're happy to wait
> > for
> > slower readers here.
> >

>
>
> Stop smoking those mushrooms. The OP never addressed physically
> securing his computer while still allowing free access to it.


ROTFLMAO!

Ok, now amuse us all by trying to explain how "free access" and
"physical security" aren't polar opposites.

 
Reply With Quote
 
Arthur T.
Guest
Posts: n/a
 
      09-30-2006
In Message-ID:<Xns984948E257AC3abcxyzcom@127.0.0.1>,
"nemo_outis" <(E-Mail Removed)> wrote:

>Free Compusec works fine and is not discenibly slower than any other full
>HD OTFE encryption product (the hit from any of them is negligible on a
>fast machine).
>
>I wouldn't worry about AES-128, it's more than strong enough. In fact, it
>is rare for a user to have a password/passphrase that comes anywhere close
>to 128-bit equivalence - the password, not the encryption, is usually the
>weakest link.


In the case of Free Compusec, the password *has* to be weaker
than AES-128. According to its documentation, the password is up
to 16 bytes and alphanumeric. Even if it's totally random, I get
it to be the equivalent of only about 95 bits (83 if case is
ignored).

--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a good MVS systems programmer position
 
Reply With Quote
 
nemo_outis
Guest
Posts: n/a
 
      09-30-2006
Arthur T. <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> In Message-ID:<Xns984948E257AC3abcxyzcom@127.0.0.1>,
> "nemo_outis" <(E-Mail Removed)> wrote:
>
>>Free Compusec works fine and is not discenibly slower than any other
>>full HD OTFE encryption product (the hit from any of them is
>>negligible on a fast machine).
>>
>>I wouldn't worry about AES-128, it's more than strong enough. In
>>fact, it is rare for a user to have a password/passphrase that comes
>>anywhere close to 128-bit equivalence - the password, not the
>>encryption, is usually the weakest link.

>
> In the case of Free Compusec, the password *has* to be weaker
> than AES-128. According to its documentation, the password is up
> to 16 bytes and alphanumeric. Even if it's totally random, I get
> it to be the equivalent of only about 95 bits (83 if case is
> ignored).
>


I haven't checked whether the password/phrase is limited to 16 bytes or
whether only alphanumeric characters can be entered. Have you confirmed
this or are you going by some documentation?

Sixteen bytes, if it could be fully used, is, of course, 128 bits - full
equivalence.

If one can only enter upper and lower case alphas & numbers, then the
maximum strength is (26 x 2 + 10)^16 which is (just over) 95 bits, as you
say.

Regards,

 
Reply With Quote
 
Arthur T.
Guest
Posts: n/a
 
      09-30-2006
In Message-ID:<Xns984E5F28F26ACabcxyzcom@204.153.244.170>,
"nemo_outis" <(E-Mail Removed)> wrote (with some unmarked snippage):

>Arthur T. <(E-Mail Removed)> wrote in
>news:(E-Mail Removed) :
>
>> In the case of Free Compusec, the password *has* to be weaker
>> than AES-128. According to its documentation, the password is up
>> to 16 bytes and alphanumeric. Even if it's totally random, I get
>> it to be the equivalent of only about 95 bits (83 if case is
>> ignored).
>>

>
>I haven't checked whether the password/phrase is limited to 16 bytes or
>whether only alphanumeric characters can be entered. Have you confirmed
>this or are you going by some documentation?


I haven't yet installed it. All I know is what I read in
TFM. This is from their readme.htm file:

The initial password after the installation of CompuSec is
"start123".
The user ID must be 1 to 16 characters long. Characters can be
alphanumeric.
The password must be 6 to 16 characters long. Characters can be
alphanumeric.

The same file says: "The security file, SecurityInfo.dat, is
unique to a computer. It can only be used for the machine where it
was initially created." That leads me to believe that if your
computer dies, but your HD is still okay, it doesn't matter.
You're SOL unless you've taken traditional backups (which I do,
anyway).

Neither of the above will necessarily keep me from installing
and using Compusec. But I thought it worth pointing out since the
OP said that Compusec supports "only" 128 bits of AES key. And,
BTW, TFM says:
Fast AES Algorithm with 128 or 256 bit key length.

Again, I haven't yet installed it, so all my information
comes from its documentation, not from its actual capabilities.
The version I downloade is 4.21.


--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a good MVS systems programmer position
 
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
connecting both computers with different operating system together naderbd Wireless Networking 1 07-29-2005 12:47 AM
Sun to Give Out Operating System for Free Rich Firefox 7 11-16-2004 07:47 PM
How to get the Operating System info like ( Wireless info, Wireless connection) Vasanth Perl 0 06-28-2004 08:56 AM
Re: 32 bit operating system Consultant MCSE 0 01-08-2004 02:58 PM
Re: 32 bit operating system Politician Spock MCSE 0 01-08-2004 02:55 PM



Advertisments