Integrity checking NANOBSD images

We have a number of Soekris devices that we will be
deploying 
remotely in semi- hostile physical environments.   The
remote links 
are dialup so I dont have a lot of bandwidth available.  I
want to do 
integrity checks of the images so that I can detect any
tampering of 
the flash image.

If I upload a static sha256 binary to /tmp on the remote box
(which 
is a RAM disk) and then do something like

e.g.
# ssh remote1.example.com "mkdir
/tmp/rand-directory"
# scp /usr/local/bin/sha256
remote1.example.com:/tmp/rand-directory/sha256
# scp /usr/local/bin/dd
remote1.example.com:/tmp/rand-directory/dd

# ssh remote1.example.com "/tmp/rand-directory/dd
if=/dev/ad2s1a 
bs=4096k | /tmp/rand-directory/sha256"
120+1 records in
120+1 records out
505389056 bytes transferred in 169.727727 secs (2977646
bytes/sec)
955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc
0685

Can I be reasonably certain the image has not been tampered
with 
?  Or are there trivial ways to defeat this check ?

The flash is always mounted read-only, so in theory nothing
should 
change with it.  Or do I need to cram on tripwire or similar
programs 
onto the nanobsd image ?

         ---Mike



------------------------------------------------------------
--------
Mike Tancsa,                                      tel +1 519
651 3400
Sentex Communications,                            mikesentex.net
Providing Internet since 1994                   
www.sentex.net
Cambridge, Ontario Canada                        
www.sentex.net/mike

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Mike Tancsa wrote:
[ ... ]
> # ssh remote1.example.com "/tmp/rand-directory/dd
if=/dev/ad2s1a 
> bs=4096k | /tmp/rand-directory/sha256"
> 120+1 records in
> 120+1 records out
> 505389056 bytes transferred in 169.727727 secs (2977646
bytes/sec)
>
955ebad583bfc0718eb28ac89563941407294d5c61a0c0f35e3773f029cc
0685
> 
> Can I be reasonably certain the image has not been
tampered with ?  Or 
> are there trivial ways to defeat this check ?

Checksumming the device image is a fine way of checking the
integrity of it, 
assuming it is read-only.  The only thing you might want to
do is use two or 
three checksum algorithms (ie, use sha256 and md5 and
something else), so that 
someone can't create a new image which matches the sha256
checksum of the 
original.

-- 
-Chuck
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

In message <44B4010E.7010809mac.com>, Chuck Swiger
writes:

>Checksumming the device image is a fine way of checking
the integrity of it, 
>assuming it is read-only.  The only thing you might want
to do is use two or 
>three checksum algorithms (ie, use sha256 and md5 and
something else), so that 
>someone can't create a new image which matches the
sha256 checksum of the 
>original.

A much better idea is to send a random "salt" to
be prepended to
the disk image before it is run through sha256, that would
prevent
the attacker from running sha256 and any other algorithm you
could care for on the image, store the results and return
them
with trojans.

Copying the sha256 binary over is no guarantee against a
kernel
embedded trojan.

But then again, how paranoid one has to be is a matter of
preference.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phkFreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained
by incompetence.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote:
>In message <44B4010E.7010809mac.com>, Chuck Swiger
writes:
>
> >Checksumming the device image is a fine way of
checking the 
> integrity of it,
> >assuming it is read-only.  The only thing you might
want to do is 
> use two or
> >three checksum algorithms (ie, use sha256 and md5
and something 
> else), so that
> >someone can't create a new image which matches the
sha256 checksum of the
> >original.
>
>A much better idea is to send a random
"salt" to be prepended to
>the disk image before it is run through sha256, that
would prevent
>the attacker from running sha256 and any other algorithm
you
>could care for on the image, store the results and
return them
>with trojans.
>
>Copying the sha256 binary over is no guarantee against a
kernel
>embedded trojan.
>
>But then again, how paranoid one has to be is a matter
of preference.


Hi,
         Thanks for the responses.  I know there are no
perfect ways. 
I guess I want to understand the risk as much as possible
and 
mitigate against tampering as much as possible without
designing the 
requirement for some guy to sit in front of the box with a
gun 

With respect to prepending a random salt to the image, can
you expand 
what you mean ?

         ---Mike


>--
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>phkFreeBSD.ORG         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be
explained by incompetence.

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

In message <6.2.3.4.0.20060711161049.04bd37a064.7.153.2>, Mike Tancsa writes:

>With respect to prepending a random salt to the image,
can you expand 
>what you mean ?

If you just run sha256 on the disk image, and the attacker
finds out, he will just run sha256 himself and record the
result.

Arming a trojan to just do 'sleep 145 ; echo "sha256
= 0248482..."'
when you thing you're running sha256 would be trivia.

If you take a random hexstring of 16 digits and prepend to
the
disk-image, then the output of the sha256 is not constant
and in order to simulate it, he has to have access to the
disk
image to feed into sha256

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phkFreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained
by incompetence.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Poul-Henning Kamp wrote:
> In message <44B4010E.7010809mac.com>, Chuck Swiger
writes:
>> Checksumming the device image is a fine way of
checking the integrity of it, 
>> assuming it is read-only.  The only thing you might
want to do is use two or 
>> three checksum algorithms (ie, use sha256 and md5
and something else), so that 
>> someone can't create a new image which matches the
sha256 checksum of the 
>> original.
> 
> A much better idea is to send a random
"salt" to be prepended to
> the disk image before it is run through sha256, that
would prevent
> the attacker from running sha256 and any other
algorithm you
> could care for on the image, store the results and
return them
> with trojans.

That suggestion is a very good point, although trying to
find a single 
trojaned image which matches several checksum methods is
supposed to be a 
highly difficult task.

-- 
-Chuck

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Tue, Jul 11, 2006 at 04:18:19PM -0400, Mike Tancsa wrote:
> At 04:05 PM 11/07/2006, Poul-Henning Kamp wrote:
> >In message <44B4010E.7010809mac.com>, Chuck Swiger writes:
> >
> >>Checksumming the device image is a fine way of
checking the 
> >integrity of it,
> >>assuming it is read-only.  The only thing you
might want to do is 
> >use two or
> >>three checksum algorithms (ie, use sha256 and
md5 and something 
> >else), so that
> >>someone can't create a new image which matches
the sha256 checksum of the
> >>original.
> >
> >A much better idea is to send a random
"salt" to be prepended to
> >the disk image before it is run through sha256,
that would prevent
> >the attacker from running sha256 and any other
algorithm you
> >could care for on the image, store the results and
return them
> >with trojans.
> >
> >Copying the sha256 binary over is no guarantee
against a kernel
> >embedded trojan.
> >
> >But then again, how paranoid one has to be is a
matter of preference.
> 
> 
> Hi,
>         Thanks for the responses.  I know there are no
perfect ways. 
> I guess I want to understand the risk as much as
possible and 
> mitigate against tampering as much as possible without
designing the 
> requirement for some guy to sit in front of the box
with a gun 
> 
> With respect to prepending a random salt to the image,
can you expand 
> what you mean ?
> 
It means that every time you want to checksum it, you send
some
random bits to be prepended to the image, then compute the
checksum(s).  You then do the same (with the same salt) on a
trusted host and compare the results.


Cheers,
-- 
Ruslan Ermilov
ruFreeBSD.org
FreeBSD committer

--- Poul-Henning Kamp <phkphk.freebsd.dk> wrote:
> Arming a trojan to just do 'sleep 145 ; echo
"sha256 = 0248482..."'
> when you thing you're running sha256 would be trivia.
> 
But what if the trojan copies its files to the RAM disc and
waits for this
sha256 binary showing up? And then, when it is there, it
removes its changes on
the hard disc  (those changes certainly must be in unused
(formerly zeroed)
areas of the hard disc or in the (zeroed) end of certain
shell scripts... Or do
I miss something?

Wasn't is usual some years ago to switch the boot disc
hardware to "read only"
mode? I dont know how to do that, but my source seemed to be
trustworthy
(although I never saw him - I just heard his voice...)...
)

A switch like on those 1.44'' floppy discs would be
good...
But then software/OS updates would require physical access
to the box...

-Arne


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

In message <20060711204521.80198.qmailweb30304.mail.mud.yahoo.com>, "R. B. Rid
dick" writes:

>Wasn't is usual some years ago to switch the boot disc
hardware to "read only"
>mode?

Some CF cards have that.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phkFreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained
by incompetence.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

At 04:34 PM 11/07/2006, Ruslan Ermilov wrote:
> > >
> > With respect to prepending a random salt to the
image, can you expand
> > what you mean ?
> >
>It means that every time you want to checksum it, you
send some
>random bits to be prepended to the image, then compute
the
>checksum(s).  You then do the same (with the same salt)
on a
>trusted host and compare the results.

OK, but that implies I have a copy of the image locally.  We
do on 
occasion make modifications to the config in the field, and
sending 
back a 512MB image over dialup would be difficult for this
deployment.

         ---Mike 

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"