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:35 ADT
Marcus Watts (mdw@umich.edu)
Wed, 17 Jun 98 01:45:37 -0400
You wrote (with some editting):
<snip>
> We are digressing a bit here; my original query more specifically
> concerns the win16 "GlobalLock" "GlobalUnlock" functions, and what
> actually occurs in 16 bit Windows when they are used.
<snip>
> ... The only way I can design an "application to be proof against that" is to
> investigate functions like "GlobalLock".
<snip>
> Lets get some perspective here ... I'm a simple shareware author,
> aspiring to do my best in the interest's of my software's users.
> If I could code my programs in such a way as to prevent my users
> being attacked by "heavy black rubber sticks" I would, but I just
> want to know about "GlobalLock".
<snip>
> Perhaps your right ... I mean whats the point ! Why go to all the
> effort to understand what happens when you call "GlobalLock", when
> someone can just go and beat-up my shareware users with "heavy black
> rubber sticks" anyway.
<snip>
> No I'm not worried about the NSA, I would just like to know about
> "GlobalLock".
You mentioned GlobalLock/GlobalUnlock 6 times, so you're quite
clearly keen on that particular point. 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'm skeptical that
using GlobalLock/GlobalUnlock is sufficient to make any claim
of computer security, mostly because I've heard enough about
MicroSoft and windows to be skeptical about *any* claims for
computer security under windows.
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. Equivalent, but less convenient results, might be
obtained by seducing the proper microsoft employee(s), if you can find
them. 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.
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. Unlike the previous method, this method will
not necessarily detect a back door built into windows by the NSA.
Also, while this method is not as much work as the previous method,
it is still a lot of work. However, this method is certainly a good way
to analyze the effectiveness of using GlobalLock/GlobalUnlock to protect
your computer's secrets against the Hungarians, the Indians, the Mafia,
and the neighborhook kids. Note this method will not detect "rubber
stick" vulnerabilities.
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. 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.
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.
You also wrote:
> Sure ... Delphi allocates memory on the stack ... every
> time my program, unit(s), or event handlers run. I simply declare my
> variables, and Delphi allocates and disposes of the memory
> automatically. If I require 128 bytes of memory then I declare a
> variable of 128 bytes ... what could be simpler !
I can't claim to know anything about delphi. In C, you might well allocate
memory either in the linker (a static or global), as an automatic variable
(and hence on the run-time stack), or via malloc. With the former two
methods, unless you tell the compiler to include debugging information,
the allocation of individual data items is not known except to the program
at run-time. Also, with these 2 methods, there is no size penalty to
small or large data items. Using malloc, however, the size of random items
is visible to the C run-time library, but not to the OS - and there *is*
a performance penalty to having more smaller objects, because of the
run-time book-keeping overhead. If you *had* to have an item that was
in "wired" memory, you would not use *any* of these methods to allocate
memory, but might instead use some variation on "mmap" - and that method
would in fact be visible to the OS, just as "GlobalLock" is visible to windows.
It is very hard to design a system that has more security or
trustworthiness than the underlying software. An interesting early famous
example of this happened with Unix early on. One of the Unix programmers
changed the compiler to recognize when the compiler or the login program
to unix was being compiled. If the login program was being compiled,
the program would slip in a "back door". If the compiler was being
compiled, then the change would compile itself into the new copy of the
compiler. Hence, you could have a complete copy of all of the source
to Unix, verify "the hack" was not in the source, compile a complete
new system from the clean source, and "the hack" would be in the
executables produced. This code was apparently secretly released
inside of AT&T, and nobody ever noticed! When it came time to
clean up after the experiment was over, it was apparently a bit
surprising just how far "the hack" had gotten distributed without
anyone ever noticing.
I had written:
> Getting back to the computer for a moment, the first and best thing
> you can do is to run an OS that is relatively immune to computer viruses.
You replied:
> Over the last three years, I have spent over 2000 hours on-line,
> during which time I have downloaded tens of thousands of
> files, and never once have I experienced a problem with a virus. I
> take care to scan new files, and over where I get them, so I don't
> need "to run an OS that is relatively immune to computer viruses" (if
> such an animal exists) as the OS has me.
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.
-Marcus Watts
UM ITD PD&D Umich Systems Group
PS. All of my Unix systems have mice and windows.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:35 ADT