"John S. Denker" <[EMAIL PROTECTED]> writes:
>On which systems is all this really an issue, and when?
The majority of them.
>Which operating systems "leak" memory between processes in this way?
Win32 via ReadProcessMemory. Most Linux systems which set up the user as root
when they install the
At 8:40 PM -0800 11/7/02, Peter Gutmann wrote:
>It's worth reading the full thread on vuln-dev, which starts at
>http://online.securityfocus.com/archive/82/297827/2002-10-29/2002-11-04/0.
>This discusses lots of fool-the-compiler tricks, along with rebuttals
>on why they could fail.
In that discus
On Thu, 7 Nov 2002, Don Davis wrote:
>* standards-compliant compilers normally distinguish
> between "conformant" source programs and "noncon-
> formant" source programs. for example, a noncon-
> formant program might be one that uses a deprecated
> feature. with nonconfo
At 8:36 AM -0800 11/8/02, bear wrote:
>I remember this issue from days when I wrote modem drivers.
>I had a fight with a compiler vendor over the interpretation
>of "volatile".
>
>They agreed with me that "volatile" meant that all *writes*
>to the memory had to happen as directed; but had taken the
At 08:58 AM 11/8/02 -0500, John S. Denker wrote:
>system. At the very least, we must pay attention to:
> -- hardware physics
BTW, there have been papers about persistance in semiconductor
memories, too. Ie, you store the same key for a long time
in a memory, and later on someone can (by subtle
"John S. Denker" <[EMAIL PROTECTED]> writes:
> 1) This topic must be taken seriously. A standard technique
> for attacking a system is to request a bunch of memory or
> disk space, leave it uninitialized, and see what you've got.
I find that this thread doesn't discuss the threat model behind
"e
I remember this issue from days when I wrote modem drivers.
I had a fight with a compiler vendor over the interpretation
of "volatile".
They agreed with me that "volatile" meant that all *writes*
to the memory had to happen as directed; but had taken the
approach that *reads* of volatile memory
[cc's pruned]
> static void
> burn_stack (int bytes)
> {
> char buf[64];
>
> memset (buf, 0, sizeof buf);
> bytes -= sizeof buf;
> if (bytes > 0)
> burn_stack (bytes);
> }
This may also not quite do what you think:
1) burn_stack() may reasonably be made tail-recurs
TGi has NEVER been all that interested in DOS attacks because a number
of people argued that all you need to do is turn on a spark gap
transmitter. While this is true, I think it is harder (one can argue
how much) to get a spark gap transmitter and use it correctly than a
laptop, NIC card, and
1) This topic must be taken seriously. A standard technique
for attacking a system is to request a bunch of memory or
disk space, leave it uninitialized, and see what you've got.
2) As regards the "volatile" keyword, I agree with Perry.
The two punchlines are:
> if, for example, gcc did not hono
No crypto here, just C language lawyering.
On Thu, 07 Nov 2002, Don Davis wrote:
> At 3:07 PM +1300 11/7/02, Peter Gutmann wrote:
> >> [Moderator's note: FYI: no "pragma" is needed.
> >> This is what C's "volatile" keyword is for.
> >
> > No it isn't. This was done to death on vuln-dev,
> > see
11 matches
Mail list logo
