M
MooseFET
They accept Windows.
-
Categories
-
Platforms
-
Content
How to develop a random number generation device
- Thread starter [email protected]
- Start date
They accept Windows.
N
Nobody
That doesn't address the issue, which was whether the OS can
prevent buffer overruns.
N
Nobody
To be a little more pedantic, no library is part of "Linux", which is the
kernel.
No, I quite definitely meant ABI. That's what determines whether a given
binary will run on a particular system; the API determines whether you can
compile your own binary from source.
Changes don't have to be major; a single missing or renamed symbol is
enough to cause a binary to fail to run. Changing a function to a macro
will do it; with C++, changing the type of a function parameter will do it
(due to mangling to deal with overloading).
Yes, but I was talking about the ABI.
That was essentially what I meant by:
With Linux, it would be feasible to change low-level details such as
calling conventions or the executable format in order to facilitate
new security mechanisms. OSes where proprietary software dominates don't
have the same freedom.
Adding members will result in binary incompatibility if the executable is
responsible for allocation (e.g. if the structure is a local or
global variable which is filled in by a library function). A library which
is expecting an "enlarged" structure will overrun the earlier, smaller
version.
Even if the library performs allocation, you can only add to the end of
the structure. This is a problem for object-oriented libraries (e.g. GUI
toolkits), where it's common to implement subclasses by appending fields
to the parent structure (both GTK+ and Xt work this way), as you can't add
fields to any class which has a subclass without breaking binary
compatibility.
V
Vladimir Vassilevsky
Rich said:
I suppose you have accounted for youself, so who are the other two?
May be, Larkin and... who? Could it be the "weenie leftist" ?
VLV
V
Vladimir Vassilevsky
True statement. However the statistics is preserved through the linear
operations. That allows for the simple analysis and exploitation.
A nonlinear operation between the two sequences such as hash, LUT, etc.
would be much better if the secure random numbers are required.
How much of that seeming randomness is really random? There is a lot of
correlation to the power supply, etc. That quasi randomness can actually
produce more of the known plaintext vectors to aid the attacker.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
operations. That allows for the simple analysis and exploitation.
A nonlinear operation between the two sequences such as hash, LUT, etc.
would be much better if the secure random numbers are required.
How much of that seeming randomness is really random? There is a lot of
correlation to the power supply, etc. That quasi randomness can actually
produce more of the known plaintext vectors to aid the attacker.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
J
John Larkin
I program engineering apps in PowerBasic, and embedded stuff in
absolute assembly. Both are fast, primitive, and bug-free. I write
good programs because I use simple tools, and because I hate to
program.
John
R
Rich Grise
Heavens, no! But at least I have enough common sense to know that
I'm _not_ competent in C++, unlike the MICRO$~1 crew! ;-)
However, I believe I could hold my own in vanilla C. ;-)
Cheers!
Rich
R
Rich Grise
With a hardware MMU, and software that can catch the exception, yes.
Cheers!
Rich
J
John Larkin
I can't prevent them, but it could and should trap them and abort the
offending task, with no possibility of subsequent damage.
Under a decent OS, bad code should only hurt itself.
John
R
Rich Grise, Plainclothes Hippie
Actually, with the *nix permissions system, that's pretty much
how it works anyway. The user can only write to subdirectories where
he has write permission, which saves disk files; as far as allocating
memory, it seems like you'd need either a hardware memory manager, or
check every freaking instruction - hey, maybe that's why they need 3 GHz
processors to add 2 + 2 these days! ;-)
Cheers!
Rich
K
krw
Of course it does.
M
MooseFET
If the pseudo-random generator is long enough, "simple" doesn't mean
anyone will get it done this week.
Yes it is better but the XOR is still a long way from "very
dangerous".
Quite a lot because it mostly is due to noise in the components.
If you do a bad design of the oscillator or the power supply perhaps.
Remember my comment about the "hit and miss" regulator. I added that
because they do not make a reapeated pattern.
Huh?
N
Nobody
That still doesn't address the question of how you decide that a write
operation has overrun its buffer; the details of where one buffer starts
and another ends are unknown to the OS.
You might be able to catch specific cases (e.g. overwriting a return
address), if you're willing to take a massive performance hit (i.e. a
context switch on all writes to the stack). Even then, that isn't the only
type of buffer overrun which can be exploited.
N
Nobody
I don't think you understand what a buffer overrun is. FWIW, it isn't
related to process isolation (preventing one process from trashing another
process' memory). That's a non-issue with modern OSes and modern CPUs (for
x86, that means 80286 and later).
A buffer overrun is where a process trashes its own memory. The memory
which is written is supposed to be written by that process, but the wrong
part of the program writes the wrong data to it (e.g. writing a portion of
a string to memory which is supposed to hold an integer or pointer).
The reason why the OS cannot do anything about this is because it lacks
the detailed knowledge regarding which portions of memory are used for
what purpose. That information is normally discarded during compilation
(unless you compile with debug information). By the time you get to
running a binary executable, you're at a level of "code writes data",
with no details about which parts of memory belong to specific variables.
N
Nobody
Please explain how "An OS can surely make it impossible to write safe
code and a real OS is required to make safe code possible" addresses the
question of whether the OS can prevent buffer overruns.
J
John Larkin
Well, Windows is not a modern OS, and x86 is not a modern processor.
Given decent hardware tools, an OS should abort a process that tries
to execute data.
There was a joke, in the DOS days, that a certain jpeg file contained
a virus. It was a joke because it was obviously impossible. A few
years later, Windows managed to make it happen.
And XP occasionally crashes when a user-level process screws up. Not
as often as '98 type systems, but it still happens. And Patch Tuesday
has become a ritual.
If the code segment was write protected and execute-only, and data
segments were not executable, and if there were separate data and
return-address stack pointers, the OS *would* know when a process does
something dangerous.
John
T
TheKraken
You're an idiot.
You're an idiot.
You're an idiot.
D
David Brown
TheKraken said:
No, he's right. It is not hard to make data segments non-executable,
and even windows can do it to some extent (blocking execution on the
stack segment). And he's also right that windows is not a modern OS -
from the day DOS 1.0 came out to the day Vista arrived, the MS OS's have
never been "modern" in terms of how they are designed and implemented.
They have had plenty of modern features, and the age of a particular
feature or idea is no indication of quality, of course.
No, he's right - I remember such hoax viruses (from early windows days
rather than DOS days - IIRC jpg did not exist so early), and Windows did
have a vulnerability allowing malware to spread by jpgs:
http://news.techwhack.com/430/microsoft-jpeg-exploit-might-result-into-a-worm-soon/
I also remember hoaxes about emails that would infect you just by
reading them - and then MS managed to turn that into reality too
(especially for those poor sods that used Outlook and had MS Office
installed).
No, that sounds like a pretty good summary. There's no doubt that the
NT line of windows is far more solid than the DOS line, but it is far
from solid enough. I have a W2K machine that stops dead when Opera is
showing certain web pages - there may be a bug in Opera, but it is
windows' fault that it stops the whole machine.
M
MooseFET
You seem to be confusing "Windows" and an "OS".
M
MooseFET
No, he is right. The Harvard architecture may be an exception because
"trying execute data" may be meaningless in that sort of processor.
Again what he said is true. The "DOS days" includes the early
versions of Windows. One version of the joke had a JPEG file that
really did have (what was claimed to be) a virus in it thanks to
someones electron microscope.
So you didn't put in the patches LOL!
