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
Simon R Knight (srk@tcp.co.uk)
Wed, 17 Jun 1998 02:56:04 0000
> > I have asked a couple of programming friends, and I get a different
> > answer from each of them. One says that such memory will be locked
> > and immoveable, and another says that it will be both locked and
> > moveable. I get the impression that although such memory is "locked",
> > that it is actually some kind of virtual lock.
>
> I think a better term here would be "pinned". ...
Quite possibly; ... which one of us should tell Bill Gates ?
> A "lock" can mean many
> things - another common use for the word "lock" is to "lock" a data
> structure so that only one control thread can use it. Another way to
> phrase this is that the lock is used to "serialize" access to the
> data structure.
... and another being a level 1, 3, or 3 disk lock ...etc. I
understand that under the win32 there are many opportunities for
controlling access to objects, but these frequently have no
counterpart under win16; e.g. threads.
> "Pinned" memory, on the other hand, could be used either by one
> thread at a time, or by many at once. All that "pinned" means is
> that it's given a fixed physical location in memory, and stays
> there. One common use for "pinned" memory is for DMA I/O. It would
> be very bad if the memory were moved while a DMA disk read were in
> progress. At best, the data wouldn't end up in the right place. At
> worst, if something else were given the use of that memory, very bad
> things could happen. Pinned memory is also often used for
> interrupts - for instance, the memory used for an interrupt handler
> is usually pinned. This is because a page fault in an interrupt
> handler is usually at least undesirable.
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.
> > If possible, it would be inifinitely preferable to *reliably* lock a
> > small amount of physical memory to hold sensitive data, than to
> > explain to software users, how their virtual memory bypasses
> > security, unless it is turned off, or set to a fixed length and wiped
> > afterwards; neither of which is ideal. I can of course wipe areas of
> > memory associated with variables that contained sensitive data, but
> > unless such data is allocated only fleetingly, there would seem every
> > possibility that the memory pointed to is no longer the physical
> > memory that was originally written to.
<snip>
<snip>
> You need to decide what kind of theat you are worried about, then
> design your application to be proof against that.
I'm not the worrying type; 34, and not a single white hair !
: )
The kind of threat that I have to consider very carefully, is
the simple kind that simply undermines otherwise secure
encryption. In the context of my earlier message, this is the Windows
OS writing sensitive data to disk, due to virtual memory options. The
only way I can design an "application to be proof against that" is to
investigate functions like "GlobalLock".
> The reason
> that people worry about mathematical security is because it's
> the one piece that shared between two different systems, and
> hence can't be "improved". Every practical system will have
> its weakpoint. In order to prove the security of that system,
> you have to identify and upgrade the weak point. If the math
> is the weak point, you can't fix it without breaking interoperability.
This sounds very abstract. I perceive mathematical security more
simply in relation to the possibilities for understanding and
attacking such security.
>
> Modern high performance computing systems are, and are not, a problem.
> The good news is that most modern machines feature hardware memory
> protection, and operating systems are available that exploit those
> features. Properly used, such systems can be highly secure.
If sensitive data can *truely* be "locked" into a physically fixed
position in memory, then encryption on a modern PC would appear to be
reasonably secure proposition.
>The
> bad news is that these modern systems also feature many high performance
> features which are both "complicated" and could "leak information", and
> that some of the most popular operating systems available have terrible
> security built into them.
If I can lock an area of physical memory that will be used to contain
sensitive data, then I can prevent this data from being swapped to
disk, and also wipe this memory afterwards. There may be a
variety of popular operating sytems in use today, but I only program
for Windows, and so the question is quite simple:
1. Can memory allocations be *absolutely* physically locked under the
different versions of Microsoft Windows.
>
> Regarding "128 byte memory allocations". You have obviously not done
> much programming.
Really !
> Programmers don't generally allocate separate
> small chuncks of 128 byte memory to hold MD5 keys.
I do ... but then I'm one of the millions of individuals that took a
step up the evolutionary ladder, and became a "Borland Delphi"
programmer !
: )
>They are much more likely to stash such things on the local stack,
to use random globals for these, ...
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 !
> ... or to allocate larger chunks of memory that might
> hold file information, a user's name, and an incidental hash.
Sure ... I can allocate blocks of memory dynamically too, however
Delphi comes with a heap manager that includes a segment
sub-allocator algorithm that greatly enhances performance and allows
a substantially larger number of blockes to be allocated. I am free'd
therefore allocating quantities of memory that are unrelated to the
size of the variables that I actually use.
> I very much doubt MicroSoft has programmed their OS to answer the modem
> when nobody is around.
... I also doubt whether the NSA or the CIA would ever pass up the
opportunity to have a backdoor into such world dominating OS. If
they wanted one, then I respect their ability to get them in one way
or another.
Considering that in a few years time, it will become as common to
have Windows (or Windows CE) machines connected to communications
lines all over the world, then it would seem inconceiveable for
backdoors not to have been engineered. It seems to be the
absolutely obvious thing for an intelligence agency to do. The
example of the modem only illustrates one simple way in which this
could be done. With the complicity (or subversion) of the OS, all
that would be needed is a pre-arranged instruction for the machine to
respond to; this could be a distinctive ring pattern, or a specific
time, or both. A couple of bytes would suffice for the instruction,
which could come from any online site, or even something as simple as
a number in a CNN "quick news" email.
If I were going to suspect MicroSoft was designing
> back doors to leak information, I'd be much more suspicious of the fact
> that MicroSoft Word stores all sorts of "incidental" garbage when you save
> your document. Even there, though, no, I don't think the NSA did that,
> I think it was purely that it was "easier" and "faster" to program word
> to act that way.
It is a little outrageous that Microsoft includes all sorts of
information in the hidden parts of its .doc files. I've noticed that
this "incidental garbage" actually includes the licenced user of the
Word program itself.
This is minor though, compared to the discovery that Microsoft
secretly programmed its Win 95 OS to monitor a very large number of
competitors products, and covertly upload this data when a user
connected to the MSN. The analysis that revealed this has been
described in some depth, on the web.
> Again, this is something you learn out of programming:
> it is faster to allocate a smaller number of larger chunks of memory than
> lots of smaller ones, and it is faster (but also more bug-prone) not to
> pre-clear memory if you're going to immediately store data into that memory.
The heap manager in Delphi automatically optimizes memory
allocations, and so although the heap manager can be bypassed, there
is little advantage in doing so.
> Regarding threats against computers, here is a partial list of
> threats to worry about:
> (1) someone might steal the computer, and gain permament
> possession of the thing.
All the more reason not to leave sensitive data like keys, passwords,
pass-phrases etc in the hard disks swapfile.
> (2) someone might "borrow" the computer, and either
> copy the data on the computer, change the
> data that is stored on the computer, or
> physically alter the computer.
All the more reason not to leave sensitive data like keys, passwords,
pass-phrases etc in the hard disks swapfile.
> (3) someone might run an active "attack" against the
> computer through a network while it's running.
> (4) someone might "passively" listen to the data being sent
> through the network to or from the computer.
I don't write client-server applications, but rather stand alone
applications, or Internet client applications, so LAN, WAN sniffing
is not a significant threat ... at least not at present.
> (5) someone might attack the person who owns the
> computer, and use large heavy black rubber sticks.
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".
> (6) someone might seduce the person's secretary and
> steal all the passwords that are hidden under the
> typewriter table.
I will be sure to warn them of this in the helpfile !
> All of these threats are possible, and all have been used in the
> past with success. It is silly to invest too much effort in increasing
> security against one form of attack, if another form of attack is left
> wide open. The bad guys are obviously not going to play fair.
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.
> It is interesting to look at how banks, which have had a long
> history of having to worry about these sorts of problems, deal with them.
> Banks tend to be a lot more keen on audit trails, alarms, and hiring
> reliable employees, than they actually worry about physical security.
> The point with a bank is not to make it impossible, but to ensure that
> it can be detected, and something actively done, when it happens.
Yes ... if there are any phantom withdrawals they actively blame it
on the account holder, or members of their family. When the banks
quietly lost 500 million in one year in electronic fraud (as did UK
banks), then they simply charged everyone per year for their credit
cards.
> 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.
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.
> That means, unfortunately, no MacOS, no MicroSoft Word, and no
> Windows.
Is Microsoft Word an OS now ... well I suppose it loads slowly
enough to be one.
...anyway, that list doesn't exactly leave much choice. Am I to
understand that I should abandon my years of Delphi programming ,
because viruses may attack Windows. What would you have me do; go
and learn Unix or something ?
> One of the many unix derivatives can be good, if set up correctly.
Ah ha ... I was right !
> Doing this, and worrying about physical security will put you way
> ahead of the game.
All I have to do is to convince my "pointum clickum" wysiwyg
users, that all they actually want is a command-line unix interface
after all. ... mouse ... who needs a mouse !
> Depending on your application, you might then want
> to worry about the other points above.
Black rubber sticks, and serialized access to an airplanes toilet ?
You unix programmers are so abstruse !
> None of these will make you immune
> to the NSA. If you are worried about the NSA, and you're using a laptop
> with windows, you are, um, "out of it".
No I'm not worried about the NSA, I would just like to know about
"GlobalLock".
Speaking of the NSA though, it is probably wise to assume that
Windows is compromised, but the NSA and the CIA will never ever
admit to it, so in practice security is maintained for the everyday
PC user. The NSA and the CIA might one day learn exactly what we're
encrypting, but they won't be able to tell anyone. This scenario is
something of a catch 22, and isn't typically figured into PRNG and
other crypto related attacks. Cryptographers are clever though, so it
is perhaps reasonable to ask what what part of the Microsoft OS would
they choose to compromise themselves, and how would they hide it in
such a way as it could never be proven ? The field of cryptanalysis
may well come embrace an OS itself, for reasons similar to those
presented above. There is a certain irony in that the only way
Microsoft (or outside agency) could protect any covert data on the
system, is by encrypting it, so it follows that somewhere in the
system, there would have to be an existing cryptographic
implementation. What would it take to locate such an implementation,
if indeed it has been writen by the same people who wrote Windows
Notepad !
Simon R Knight
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:35 ADT