[Asterisk-Users] Re: Advice on OS Choice

[Andrew Kohlsmith]

On Friday 15 October 2004 23:28, Joe Greco wrote:
> > I know what you're trying to do (we're both playing Devil's Advocate).

> Not really.  There is a product.  If you go into a hospital for major
> surgery today, you stand a nontrivial chance of being hooked up to a
> descendant of the device in question.

I'm guessing some kind of anaesthetic or vital sign monitoring system -- but 
regardless, my argument stands -- with correct design and correct policy in 
place Bad Things won't happen.  If you have a poor design or poor policy, or 
if policy is not followed, well then Bad Things are MUCH more likely to 
occur.  With or without source being available.

I suppose that having source can make the possibility for the occurance of Bad 
Things marginally higher but it all comes down to design and policy, IMO.

> > If it's life critical machinery it *should* be difficult to alter the
> > images. Routine maintenance should not include ways to alter these
> > critical aspects of the system.
>
> Remove hard drive.  Mount on other system.  Putz.  Reinstall hard drive.

Firmware that boots checks image (or critical parts of image) for tampering 
against stored checksum (checksum that gets updated when correct update 
procedure is followed) -- Putz away, the firmware will still bring you to a 
full stop because it detected a problem.

> We had techniques to defend against that, because the system could do an
> integrity check, and the first part of that - the init module - was a
> black box unknown.  If you messed with the modules, it wouldn't start.
> If you tried to sandbox the init, it wouldn't start.  If you tried to
> replace the init with the OS vendor's init, nothing would work at all.

Sounds great, that's exactly what I'm saying.  :-)

> You can't say "well don't let them pull the hard drive", because drives
> can and do fail, and different versions of the product required different
> hard drives on the same base chassis anyways.

I didn't say that.  :-)

> That's the point.  When you give someone the source to the system, they can
> *inspect* your protection system, or worse, modify it, install it, and
> defeat it, because then they can see how it's supposed to work, and once
> you understand that, causing it to do something else becomes much easier.

The protection should not be defeatable even with the source, just as having 
the algorithm for an encryption system publically available.  If you can 
defeat it that easily then it's broken before you even sold a single unit.

> An encryption algorithm can be crappy or excellent.  If it is excellent,
> you can gain an understanding of how it works, but you will be unable to
> decrypt data without the key, which is an external factor.

> The problem with any integrity verification system which can be altered
> is that you can inevitably alter the decision logic to indicate that the
> image is good.

I don't recall ever stating that the protection against software tampering 
should be alterable or even on the hard drive -- it should be part of the 
firmware that the system uses to boot and ideally a hardware protection that 
is not (easily) alterable -- perhaps a vendor key that gets sent whenever 
software updates are sent...  To upgrade you can install the CD or reimage 
the drive with the new image, but you have to also replace the vendor key.

Hell even simply signing the critical executables with the vendor's key will 
stop any kind of dirty GNU hippie from making "insignificant" changes to the 
system software; having the source does not make it any easier to update the 
system, you still need the correct checks and balances.

> This is substantially different from the encryption algorithm, where no
> amount of modifying the decryption code will result in the decryption
> code doing its work successfully without that key.

I disagree, and give my reasons in the above two paragraphs.

> This is also why copy protection schemes have been successfully broken for
> years and years and years.  It's not a question of /if/.  It's a question
> of /how much work/.  A copy protection scheme is, after all, just a
> variation on an integrity verification system.

Agreed.  You can't possibly tell me that you expect a court to hold a vendor 
liable when you can prove that the person updating the software went through 
significant hoops and drastically altered the way the system works to get 
their rogue binaries to work?  (ok maybe you can, there have been some 
*weird* outcomes in the justice system)

> If it were even possible to "properly design" such a system and arrive at
> something that couldn't be gamed, I'm sure that the largest software
> company on the planet would have done it by now.

This whole trusted computing initiative makes it damn hard to get around.  DVD 
wouldn't have been broken if the implementation wasn't "corrupted" by a 
vendor screwing up the DVDs they produced; XBox no-modchip hacks wouldn't 
exist without software bugs...  You get the idea.

-A.