25 Jun
2006
25 Jun
'06
7:25 p.m.
I'm not sure if this is too technical for discussion
here -- except for hysterical raisins...
Are there any OS's that have implemented (non-trivial)
signatures on loading executables as a scheme of protecting
the operating environment? I.e. something more than
verifying the proper COFF/ELF/etc. load format...
--don
25 Jun
25 Jun
7:29 p.m.
Don Y wrote:
I'm not sure if this is too technical for
discussion
here -- except for hysterical raisins...
Are there any OS's that have implemented (non-trivial)
signatures on loading executables as a scheme of protecting
the operating environment? I.e. something more than
verifying the proper COFF/ELF/etc. load format...
Grrr... sorry, I should qualify this: I mean as it applies
to "general purpose" computing (NOT to "appliances").
Thanks!
--don
7:27 p.m.
Don Y wrote:
Grrr... sorry, I should qualify this: I mean as it
applies
to "general purpose" computing (NOT to "appliances").
I seem to recall Windows 2000 (and later) checks the CRC on the application
before it loads it - maybe that just covers the PE (Portable Executable)
header, but I heard of a fair bit of software that would run on Win9x, but not
on the NT series OSes, because of some checksum issue.
As far as *nix goes, I think Linux just checks the ELF signature and
executable header checksum. Don't take that as the gospel truth though, I
haven't done any major research into the ELF file format...
And of course there's games consoles (the Xbox, Xbox360 and Nintendo DS do
cryptographic checks on software before it's allowed to run), but that's not
really "general purpose computing".
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G ViewFinder
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
8:13 p.m.
As far as *nix goes, I think Linux just checks the ELF
signature and
executable header checksum. Don't take that as the gospel truth though, I
haven't done any major research into the ELF file format...
OS-90 (at least the 6809 version) checks that the module header is valid,
and then, IIRC, that the module itself has the right checksum. This is
not for any security reason, though, it's because at boot-up, OS-9 checks
all of memory for valid modules. If it finds any, it links them into the
module table, etc. Therefore you can stick OS-9 modules in ROM, just
about anywhere in the memory map, and the OS will find them. Of course to
do this safely, the system has to be very unlikely to consider random
data as a valid module, hnece the check on the header and the module body.
-tony
9:29 p.m.
Tony Duell wrote:
But, doesn't PC BIOS do essentially the same thing? (though
only looking for some really *gross* header signature -- AA55?)
As far as *nix
goes, I think Linux just checks the ELF signature and
executable header checksum. Don't take that as the gospel truth though, I
haven't done any major research into the ELF file format...
OS-90 (at least the 6809 version) checks that the module header is valid,
and then, IIRC, that the module itself has the right checksum. This is
not for any security reason, though, it's because at boot-up, OS-9 checks
all of memory for valid modules. If it finds any, it links them into the
module table, etc. Therefore you can stick OS-9 modules in ROM, just
about anywhere in the memory map, and the OS will find them. Of course to
do this safely, the system has to be very unlikely to consider random
data as a valid module, hnece the check on the header and the module body. 
9:52 p.m.
On 6/25/2006 at 2:29 PM Don Y wrote:
But, doesn't PC BIOS do essentially the same thing?
(though
only looking for some really *gross* header signature -- AA55?)
Most also have at least an 8 bit residue checksum such that the arithmetic
sum of the entire ROM (modulo 256 or 65536) is 0.
--Chuck
10:08 p.m.
It's also noteworthy that some systems which can accept Intel-format
binaries use the per-record checksum.
Cheers,
Chuck
9:27 p.m.
Philip Pemberton wrote:
Don Y wrote:
> Grrr... sorry, I should qualify this: I mean as it applies
> to "general purpose" computing (NOT to "appliances").
[snip]
And of course there's games consoles (the Xbox,
Xbox360 and Nintendo DS
do cryptographic checks on software before it's allowed to run), but
that's not really "general purpose computing".
Yes, that's why I added the "appliances" disclaimer :>
Most of those are "load once" applications. I'm curious
as to just how much overhead OS's are willing to expend
loading "typical" applications...
8:26 p.m.
IBM System/38 (and later the AS/400 and all of it's renamed versions)
run a CRC over programs for security reasons, not just for correctness
checking. It's necessary because everything is in one big address
space, so an errant program can cause security problems or crash the
system by corrupting other storage.
Don Y wrote:
I'm not sure if this is too technical for
discussion
here -- except for hysterical raisins...
Are there any OS's that have implemented (non-trivial)
signatures on loading executables as a scheme of protecting
the operating environment? I.e. something more than
verifying the proper COFF/ELF/etc. load format...
--don
9:33 p.m.
Don Y wrote:
> Are there any OS's that have implemented (non-trivial)
> signatures on loading executables as a scheme of protecting
> the operating environment? I.e. something more than
> verifying the proper COFF/ELF/etc. load format...
Michael B. Brutman wrote:
IBM System/38 (and later the AS/400 and all of
it's renamed versions)
run a CRC over programs for security reasons, not just for correctness
checking. It's necessary because everything is in one big address
space, so an errant program can cause security problems or crash the
system by corrupting other storage.
Ah, excellent! But, is their intent to catch "incorrectness"
caused by, e.g., hardware failures? I.e., do they assume they
are operating in a HOSTILE environment or just an UNFRIENDLY
one?
For example, most machine's bootstrap code contains checksums.
But, you can usually hack those images if you spend a little
time tweeking the checksum in the process (so the code thinks
everything is fine).
OTOH, cryptographic signatures are *designed* to prevent
(uh, "strongly discourage" :> ) this.
10 p.m.
Don Y wrote:
Ah, excellent! But, is their intent to catch
"incorrectness"
caused by, e.g., hardware failures? I.e., do they assume they
are operating in a HOSTILE environment or just an UNFRIENDLY
one?
For example, most machine's bootstrap code contains checksums.
But, you can usually hack those images if you spend a little
time tweeking the checksum in the process (so the code thinks
everything is fine).
OTOH, cryptographic signatures are *designed* to prevent
(uh, "strongly discourage" :> ) this.
I can't tell you the particulars because I don't know them. However,
the OS does sign the binaries to detect tampering, for both security
reasons and to ensure that IBM gets what IBM thinks is due. ;-)
The bootstrap code on something like an S38/AS400/iSeries is like an
entire operating system by itself, and I have no idea of what that code
is protected by, or even what it is running on this week. (The machine
uses a 'service processor' for at least part of the self-check and boot.)
26 Jun
26 Jun
12:18 a.m.
I forgot one--we put loader record checksums into DX85 for Durango (circa
1977) also. We didn't have a raw executable memory image
format--everything to be loaded had to be in that format (even the
operating system itself) which resembled Intel .HEX format, even to being
in ASCII rather than binary.
Cheers,
Chuck
2:14 a.m.
Are there any OS's that have implemented
(non-trivial) signatures on
loading executables as a scheme of protecting the operating
environment? I.e. something more than verifying the proper
COFF/ELF/etc. load format...
You might want to look at NetBSD's veriexec. I don't really know much
about it, but from what I've seen fly by on the lists, it sounds like
what you're looking for here.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6764
days inactive
6765
days old
12 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
dgy＠DakotaCom.Net -
mbbrutman-cctalk＠brutman.com -
mouse＠Rodents.Montreal.QC.CA -
philpem＠dsl.pipex.com