Prev: CY7C68013A:ezusb.sys driver receives a trash data
Next: STM32 and USB examples
From: D Yuniskis on 1 Jul 2010 23:19
Hi,

I'm deploying a prototype of a distributed system to
benchmark some algorithms before committing to final
hardware.

I have a large supply of 1GHz, 1GB diskless workstations
that I'll use (headless) as they are freely available,
small, reasonably (ha!) low power, etc. Almost everything
is written in portable languages so the fact that this
is x86 doesn't impact my codebase.

For the prototype system, I'll deploy 30 of these.
Most will be 100BaseTX ethernet. Some will be 802.11g
or n. A single server hosts images.

Since these are COTS boxes (and *diskless*), they are
indistinguishable from each other besides MAC. And,
MAC can be spoofed :-/

I was originally thinking of PXE booting each box. Then,
letting that bootstrap bring up the *secure* network for
the rest of IPL (key exchange, etc.).

But, I don't see any way that I can do this *without*
controlling the loading of the initial (PXE) image!
I.e., an attacker could intercept the PXE boot
request and force arbitrary code to be executed.
So, even if I added some local key storage, that
code could freely examine the key, reset the
processor and let the *next* PXE boot request go
through "as normal".

It seems like I *must* make the PXE sequence secure
if I want to have any hope of the rest of the process
being secure (?). I.e., boot locally (add some sort
of medium) and implement my own form of PXE boot. :<

However, the number of "tricks" that these folks
come up with for working in spite of adversary leaves
me never quite sure if someone hasn't already come
up with a workaround for this sort of situation -- ?

Any ideas?

Thx,
--don
From: Tauno Voipio on 2 Jul 2010 04:54
On 2.7.10 6:19 , D Yuniskis wrote:
> Hi,
>
> I'm deploying a prototype of a distributed system to
> benchmark some algorithms before committing to final
> hardware.
>
> I have a large supply of 1GHz, 1GB diskless workstations
> that I'll use (headless) as they are freely available,
> small, reasonably (ha!) low power, etc. Almost everything
> is written in portable languages so the fact that this
> is x86 doesn't impact my codebase.
>
> For the prototype system, I'll deploy 30 of these.
> Most will be 100BaseTX ethernet. Some will be 802.11g
> or n. A single server hosts images.
>
> Since these are COTS boxes (and *diskless*), they are
> indistinguishable from each other besides MAC. And,
> MAC can be spoofed :-/
>
> I was originally thinking of PXE booting each box. Then,
> letting that bootstrap bring up the *secure* network for
> the rest of IPL (key exchange, etc.).
>
> But, I don't see any way that I can do this *without*
> controlling the loading of the initial (PXE) image!
> I.e., an attacker could intercept the PXE boot
> request and force arbitrary code to be executed.
> So, even if I added some local key storage, that
> code could freely examine the key, reset the
> processor and let the *next* PXE boot request go
> through "as normal".
>
> It seems like I *must* make the PXE sequence secure
> if I want to have any hope of the rest of the process
> being secure (?). I.e., boot locally (add some sort
> of medium) and implement my own form of PXE boot. :<
>
> However, the number of "tricks" that these folks
> come up with for working in spite of adversary leaves
> me never quite sure if someone hasn't already come
> up with a workaround for this sort of situation -- ?
>
> Any ideas?
>
> Thx,
> --don


PXE, and BOOTP / DHCP, is pretty promiscuous. The machine
being booted up is not selective to the boot image sent to it
nor to the server sending the image.

There are two kinds of attack to consider:

a) An unauthorized client attempts to get an authorized image,
b) An unauthorized server attempts to feed a fake image.

The MAC spoofing applies to a).

The problem is much the same as in HTTPS. You may need to
verify both the server and the client. To do this, you need
to install in a client both an individual client key and
the common server key, so the basic PXE boot code is not
sufficient.

The keys have to be exchanged in a secure way, either with
asymmetric encryption or challenge-response exchange with
symmetric encryption.

Just my .02 EUR.

--

Tauno Voipio
tauno voipio (at) iki fi

From: Glyn Davies on 2 Jul 2010 05:25
D Yuniskis <not.going.to.be(a)seen.com> wrote:
> Hi,
>
> I'm deploying a prototype of a distributed system to
> benchmark some algorithms before committing to final
> hardware.
>
> I have a large supply of 1GHz, 1GB diskless workstations
> that I'll use (headless) as they are freely available,
> small, reasonably (ha!) low power, etc. Almost everything
> is written in portable languages so the fact that this
> is x86 doesn't impact my codebase.
>
> For the prototype system, I'll deploy 30 of these.
> Most will be 100BaseTX ethernet. Some will be 802.11g
> or n. A single server hosts images.
>
> Since these are COTS boxes (and *diskless*), they are
> indistinguishable from each other besides MAC. And,
> MAC can be spoofed :-/
>
> I was originally thinking of PXE booting each box. Then,
> letting that bootstrap bring up the *secure* network for
> the rest of IPL (key exchange, etc.).
>
> But, I don't see any way that I can do this *without*
> controlling the loading of the initial (PXE) image!
> I.e., an attacker could intercept the PXE boot
> request and force arbitrary code to be executed.
> So, even if I added some local key storage, that
> code could freely examine the key, reset the
> processor and let the *next* PXE boot request go
> through "as normal".
>
> It seems like I *must* make the PXE sequence secure
> if I want to have any hope of the rest of the process
> being secure (?). I.e., boot locally (add some sort
> of medium) and implement my own form of PXE boot. :<
>
> However, the number of "tricks" that these folks
> come up with for working in spite of adversary leaves
> me never quite sure if someone hasn't already come
> up with a workaround for this sort of situation -- ?
>
> Any ideas?
>
> Thx,
> --don

The good, old, chicken and egg prob

Are the devices physically secure?
If not the there is always a risk

Do a PXE boot and once up and running use a smartcard or other physical
dev to auth the connection to the net?

What is your secure network anyway?
Do you have 802.1x or anything?

It's a prototype anyway, so how extreme are the lengths you need to go
to?

Glyn
From: Boudewijn Dijkstra on 2 Jul 2010 06:04
Op Fri, 02 Jul 2010 05:19:33 +0200 schreef D Yuniskis
<not.going.to.be(a)seen.com>:
> I'm deploying a prototype of a distributed system to
> benchmark some algorithms before committing to final
> hardware.
>
> I have

"I have" is the keyword here. You have control over the network.
Physical control for wired communications is easy; for any wireless-only
boxen you could put them in a shielded room.


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
From: Jim Stewart on 2 Jul 2010 13:07
D Yuniskis wrote:
> Hi,
>
> I'm deploying a prototype of a distributed system to
> benchmark some algorithms before committing to final
> hardware.
>
> I have a large supply of 1GHz, 1GB diskless workstations
> that I'll use (headless) as they are freely available,
> small, reasonably (ha!) low power, etc. Almost everything
> is written in portable languages so the fact that this
> is x86 doesn't impact my codebase.
>
> For the prototype system, I'll deploy 30 of these.
> Most will be 100BaseTX ethernet. Some will be 802.11g
> or n. A single server hosts images.
>
> Since these are COTS boxes (and *diskless*), they are
> indistinguishable from each other besides MAC. And,
> MAC can be spoofed :-/
>
> I was originally thinking of PXE booting each box. Then,
> letting that bootstrap bring up the *secure* network for
> the rest of IPL (key exchange, etc.).
>
> But, I don't see any way that I can do this *without*
> controlling the loading of the initial (PXE) image!
> I.e., an attacker could intercept the PXE boot
> request and force arbitrary code to be executed.
> So, even if I added some local key storage, that
> code could freely examine the key, reset the
> processor and let the *next* PXE boot request go
> through "as normal".

> It seems like I *must* make the PXE sequence secure
> if I want to have any hope of the rest of the process
> being secure (?). I.e., boot locally (add some sort
> of medium) and implement my own form of PXE boot. :<
>
> However, the number of "tricks" that these folks
> come up with for working in spite of adversary leaves
> me never quite sure if someone hasn't already come
> up with a workaround for this sort of situation -- ?

I've gotta ask, is this a theoretical problem or are
you really concerned with someone hacking your prototype?

What kind of a prototype environment would you have that
you'd be worried about spoofed MAC addresses?

As others have pointed out, physical security should
be the first goal.

Assuming you really are concerned with someone hacking
your prototype network, wouldn't it be enough just to
*detect* a rouge PXE server? That should be easy enough.

Likewise, it should be possible to detect that your PXE
server has downloaded and validated one and only one good
image to each MAC address. With the existence of a
spoofed MAC, there should ultimately be more than one.

Finally, you could have a honeypot node. It could be
running an app that would look like a node wanting to
PXE boot, then validating the boot code it gets and
sounding an alarm if it's suspect. In fact, the PXE
server should be able to run a process that detects
other suspicious PXE servers. You could even bait
them with an inert boot and see who responds...






 |  Next  |  Last
Pages: 1 2 3 4
Prev: CY7C68013A:ezusb.sys driver receives a trash data
Next: STM32 and USB examples