[nycbug-talk] MS moves on. . .

[Bob Ippolito]

On May 20, 2004, at 10:31 AM, Dan Langille wrote:

> On Thu, 20 May 2004, Pete Wright wrote:
>
>> G.Rosamond wrote:
>>
>>>
>>> However, one thing Theo mentioned in his Exploit Mitigation
>>> Techniques  talk was about OBSD's use of canaries to avoid buffer
>>> overflows.   Apparently, MS is doing the same, although their
>>> placement of canaries  does nothing.  It would be good if someone
>>> could elaborate on the role  of canaries. . .
>>>
>> from what i understood was that MS inserts the canaries at compile 
>> time,
>> not run time.  so the canarie is in the same location on each build of
>> windows.  still confused as to what a canarie is tho...
>
> It's not that it's in the same location, it's always the same value.  A
> canary refers to the practice of carrying them into mines.  If the 
> canary
> dies, the air is bad, get out.
>
> This canary is a random value.  If it changes, something has gone 
> wrong.
> Get out.  In this case, the value is created at compile time.  So 
> it'll be
> the same value every time it runs.  Which means it isn't random.

The thing that's interesting about OpenBSD's implementation is that 
it's used as a security measure.  In most other environments, code is 
generally trusted to work correctly, and these sorts are things are 
used only in debug builds of applications to help programmers fix their 
crappy code.

The same sort of technique is used to see if you're overflowing the 
heap too, by marking a couple bytes at the end of a buffer and checking 
to see if that canary has died when the allocation is freed.  A more 
aggressive technique (called MallocGuard on OS X, not sure what it's 
called elsewhere) is to do a page allocation for every malloc, and 
allocate the next page as unwritable, so that you get an exception 
exactly when the incorrect code is being run.  I don't think OpenBSD 
does either of these by default in production applications, since it 
has a pretty gnarly performance impact.  However, since the heap is 
going to be primarily W^X where available in OpenBSD, it's not as much 
of a concern.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://lists.nycbug.org/pipermail/talk/attachments/20040520/1db62cf5/attachment.bin