[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [Full-disclosure] Apple Safari 4 Beta feeds: URI NULL Pointer
From:       Biz Marqee <biz.marqee () gmail ! com>
Date:       2009-02-27 6:54:41
Message-ID: a741a45f0902262254i2460c3e6vbc9d3a6c3c56107f () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I don't think you understand what a NULL pointer dereference is. It is
referencing NULL. NULL as in 0x00. Not 0x00+some_reg, that would now be
something greater than 0 and hence IT IS NOT DEREFERENCING NULL.. AKA NOT A
NULL DEREFERENCE.

His point remains valid, how is a free(NULL) exploitable for code execution
from userland? How does it constitute a security vulnerability?


-- snip --


>* I'm didn't even comment on Mark's paper, it is definitely a great piece of
*>* research, there is no doubt. It's just that some people have read this paper
*>* and thought, wow, all those NULL bugs are now exploitable. It's important to
*>* separate these bug classes.
*
sorry to interrupt your self-aggrandizing tirade, however you're the only
one who took the implication that *all* null ptr related bugs are
exploitable-- i never implied or said that, just said in some instances
they can be. Furthermore, I think you're taking the word 'dereference' a
little too serious and you should perhaps take up a hobby such as baseball
cards or miniature collectibles to quench you're apparent need to
sub-categorize into nothing. If you want to insist that null+x/etc bugs be
in an entirely separate category than dereferences, that's cool, just don't
go all ape-shit on people who dont share your same narrow view at
some feeble attempt at elitism via syntactic pedantry.

[Attachment #5 (text/html)]

I don&#39;t think you understand what a NULL pointer dereference is. It is =
referencing NULL. NULL as in 0x00. Not 0x00+some_reg, that would now be som=
ething greater than 0 and hence IT IS NOT DEREFERENCING NULL.. AKA NOT A NU=
LL DEREFERENCE.<br>
<br>His point remains valid, how is a free(NULL) exploitable for code execu=
tion from userland? How does it constitute a security vulnerability?<br><br=
><br>-- snip --<br><br><br><pre>&gt;<i> I&#39;m didn&#39;t even comment on =
Mark&#39;s paper, it is definitely a great piece of<br>
</i>&gt;<i> research, there is no doubt. It&#39;s just that some people hav=
e read this paper<br></i>&gt;<i> and thought, wow, all those NULL bugs are =
now exploitable. It&#39;s important to<br></i>&gt;<i> separate these bug cl=
asses.<br>
</i><br>sorry to interrupt your self-aggrandizing tirade, however you&#39;r=
e the only<br>one who took the implication that *all* null ptr related bugs=
 are<br>exploitable-- i never implied or said that, just said in some insta=
nces<br>
they can be. Furthermore, I think you&#39;re taking the word &#39;dereferen=
ce&#39; a<br>little too serious and you should perhaps take up a hobby such=
 as baseball<br>cards or miniature collectibles to quench you&#39;re appare=
nt need to<br>
sub-categorize into nothing. If you want to insist that null+x/etc bugs be<=
br>in an entirely separate category than dereferences, that&#39;s cool, jus=
t don&#39;t<br>go all ape-shit on people who dont share your same narrow vi=
ew at<br>
some feeble attempt at elitism via syntactic pedantry.<br><br></pre><br>


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[prev in list] [next in list] [prev in thread] [next in thread]