Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:37 ADT
Simon R Knight (srk@tcp.co.uk)
Wed, 17 Jun 1998 21:12:50 0000
On 17 Jun 98 at 1:45, Marcus Watts wrote:
> You mentioned GlobalLock/GlobalUnlock 6 times, so you're quite
> clearly keen on that particular point.
It shows ? : )
I would extend my query to include both page and segment locking now.
It is said that the best way
> to analyze the vulnerability of a cryptographic function is to to try
> to break it, and the best way to learn how to design functions that are
> hard to break, is to become an expert at breaking them first. This
> applies just as much to computer security software.
I do not have the specialized knowledge to break anything other than
the simple cryptographic functions, so learning by defeating them
is not an option. I could of course observe whether a cryptographic
implementation loses sensitive data to the hard disk, but due to the
lack of any apparent investigation into this issue, I imagine that
this is actually something that has been glossed over, and is
occuring all the time.
> I'm skeptical that
> using GlobalLock/GlobalUnlock is sufficient to make any claim
> of computer security, ...
I do not plan to place a level trust in a function like GlobalLock,
or any other locking functions, without conducting a good number of
tests, under different versions and modes of the Windows OS, but it
would be helpful if I could gain a rapid insight into the
considerations surrounding their use.
> mostly because I've heard enough about
> MicroSoft and windows to be skeptical about *any* claims for
> computer security under windows.
If the Macintosh OS, or version of Unix like Linux were in as
extensive use as Windows, then there could well be similar skepticism
directed toward them also.
> The *best* way to understand what GlobalLock/GlobalUnlock do, is to get
> ahold of some sort of hardware 386 emulator with trace/debug features,
> trace Windows as it executes this call, and find out what it does. You
> may have to do quite a bit of additional research on windows in order to
> completely understand your results, but if you *really* want to
> understand the full security ramnifications of using this call, this
> is the only way.
I can't lay my hands on an Intel hardware emulator ... they cost a
fortune, and this kind analysis is beyond my present resources.
> Equivalent, but less convenient results, might be
> obtained by seducing the proper microsoft employee(s), if you can find
> them.
There aren't any on this side of the Atlantic.
>The results will be less convenient because microsoft clearly has
> not traditionally placed much value on building computer security into
> their products, and hence the employee(s) in question are not likely
> to have an intelligent answer to your question. You may be reduced to
> getting them to hand over design documents and source code. Of course,
> unless you are very rich and highly skilled, this method may not be practical.
I'm not "rich and highly skilled". : (
> Less accurate, but less complicated results might be obtained by
> treating GlobalLock/GlobalUnlock as a black block mystery,
> experimentally using them, then examining the results in memory and
> on disk to see if they leaked any cryptographically useful
> information. The goal here would be to abuse them in ways that
> might cause them to behave badly, then seeing if they left
> anything nasty around. A typical example might be something
> that calls GlobalLock on some memory, writes some unique value
> to the memory in question, then allocates and frees enough additional
> memory to push everything out to disk, then reads through the disk
> and through all of main memory to see if there's more than copy
> of the unique value.
This is the approach that I will eventually take, although for now, I
would like to determine what work - if any - has already been done in
this area. I have checked the Microsoft knowledge base, but there is
virtually nothing there on the GlobalLock function. I will checkout
info other locking functions tonight.
> If you do either of these approaches, you might want to publish
> your results. I don't know of anyone who has done this work yet,
> and suspect there is no such person, because nobody has said anything
> about it on this list.
Any cryptographic implementation that does not address this issue,
is doing little more than presenting the illusion of security. I find
it inexplicable that something so fundamental can be ignored, when so
many PC encryption products are being sold on the market today.
If I were to write a utility that allowed users to monitor what
happened to passwords, passphrases, and session keys in computer
memory, I wonder how many PC encryption products will be seen
to fail !
> You should also try your approach
> under more than one version of Windows. 3.1, 95, 98, & NT may
> all do things differently, and what may be perfectly safe on one,
> may be bad news on another.
I presently have three versions of Windows on my system, but I'm
planning to install quite a few more.
> If you are reasonably well convinced the NSA/CIA has put monitoring
> traps into Windows, then you might want to consider this: calling
> GlobalLock on a small section of memory might be *just* the thing
> their monitoring trap is looking for. You are, after all, advertising
> that the item in question has possible cryptographic value.
Absolutely ! But if I lock (and fix) at segment level ...
something which according to Delphi is done by default for global
heap allocations via its heap manager (to protect the segment
sub-allocator algorithm) then everything may appear normal. I must
look into the true effects of setting the segment attributes that
suposedly fix data in physical memory, but if I eventually employ
this kind of locking, then itmay be so uncharacteristic of existing
PC encryption software, that it may perversely stand more of a chance
of going unnoticed. : )
> It is very hard to design a system that has more security or
> trustworthiness than the underlying software. ...
Yes ... I will be happy if I can simply *reliably* provide a level
of security that protects users of my software from other users who
may be armed with utilities that snoop for sensitive data writen to a
swapfile.
<snip>
> You miss my point. I'm not interested in whether you've ever gotten
> a virus. My point is that the sorts of hooks that provide an environment
> where viruses can flourish, is *also* the sort of environment that
> provides enough hooks for malicious software to compromise the
> cryptographic integrity of the machine in question. A classical example
> of this is the "keyboard sniffer", often found in university labs
> where it is used by computer vandals to steal passwords. If
> the OS can't guarantee that another application can't (for instance)
> monitor calls to GlobalLock/GlobalUnlock, then in evaluating the
> security worthiness of a particular feature you can't just worry about
> the OS (and by extension MicroSoft), but every other application that
> might be running on that machine, and every other programmer in the world.
This is clearly a genuine security issue; I imagine that it would be
quite simple (for e.g.) for popular utility to monitor for PGP
passwords or passphrases, and record them. It was thoughts like these
these led me to conclude that the OS itself is the perfect spy. Plug
in a microphone too, and it probably has an orgasm !
Security issues like those you just raised can be addressed to
varying degrees, but for now ... for me, they are something of a
future consideration where my own softwares concerned. A simply
dedicated, unconnected PC for encryption is always a private option,
as are encrypted volumes offered by software like "BestCrypt".
> PS. All of my Unix systems have mice and windows.
Is that with X Windows ... or are there additional shells of this
kind ?
Simon R Knight
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:37 ADT