Hi Nate:<br><br><div><span class="gmail_quote">On 7/25/07, <b class="gmail_sendername">Nate McFeters</b> <<a href="mailto:nate.mcfeters@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">nate.mcfeters@gmail.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hey Waldo,<br><br>As always with exploits, it's difficult to predict how they will<br>interact in every environment they may be accessed in. </blockquote><div><br>
No is not with the exploit. I actually haven't tried it. In fact I'm a
little outdated (and with a couple extra bugs). <br><br><a href="http://www.mozilla.org/security/announce/2007/mfsa2007-25.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-25</a>
XPCNativeWrapper pollution<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-24.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-24</a>
Unauthorized access to wyciwyg:// documents<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-23.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-23</a>
Remote code execution by launching Firefox from Internet Explorer<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-22.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-22</a>
File type confusion due to %00 in name<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-21.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-21</a>
Privilege escalation using an event handler attached to an element not in the document<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-20.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-20</a>
Frame spoofing while window is loading<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-19.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-19</a>
XSS using addEventListener and setTimeout<br>
<a href="http://www.mozilla.org/security/announce/2007/mfsa2007-18.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">MFSA 2007-18</a>
Crashes with evidence of memory corruption<br><br>I have <a href="http://2.0.0.4" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.0.0.4</a> here and
I'll wait for <a href="http://2.0.0.6" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.0.0.6</a> so I can skip at least one update. So there is no
point to test that bug. Updates come sometimes in days. Is hard to
follow over a dialup, even automatic updates take a while. I prefer to
download a full version instead of an auto update because that way I
don't have to download the updates again if someday I decide to
reinstall it or something. If you could apply updates to setups and
automagically for example get <a href="http://2.0.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.0.0.5</a> out of <a href="http://2.0.0.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
2.0.0.1</a> well that could be
great too but I guess that is to ask too much for now. Keep in mind that
with Internet Explorer you can do something like this so is *better* in
that area. Yes I know diff and patch could do the trick for open source
programs but then that is not productive (and not everyone is capable
of that and not everyone has time for that however I'm considering to
download the build environment + FF sources just to get away from those
tedious downloads if they decide to maybe provide us with a .diff from version to version because downloading 36 Mb from CVS is not funny over dialup. CVS can't resume).<br>
<br>
I'm sure the bug is there because on <a href="http://2.0.0.4" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.0.0.4</a> when I click on a mailto:
urls or left click on a page and I click on "send link" I get 45
explorers opened, sometimes other numbers it depends. Probably that is
related to the bug, <a href="http://2.0.0.1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.0.0.1</a> was not giving me this. Maybe that info is
useful to track the bug too. Is so broken right now. (I took
administrative rights away from the account I'm using and I don't have
a default mail application installed). To be fair is not completely a
FF fault. I tried a mailto URL in IE and it does the same thing (that's
not my concern I don't use that thing. Is simply wasting space in my
hardrive). FF is broken in the way that it tries to open it without
checking that a default MTU is installed. And I really care about this
one. And I don't like at all that it tries to open the MTU when
clicking on those URLs without too much choices to change that.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you have<br>launch external URI's on by default, the tab issue will come up;
<br>however, the exploit should still occur.<br>
</blockquote><div> <br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I'd recommend turning off<br>the launch external URI's feature for your own safety though.
</blockquote><div><br>
Yes probably Acrobat Reader shares the guilt this time reconfiguring my
Firefox (and everybody's else around) when installed without telling
me. Hey what about the browser detecting that kind of modification by
third party software? I'm sure that acrobat is not the only one doing
that without telling you.<br>
<br>
Also those media files open by default with media player plugin. Many
times we have seen those kind of files being the source of security
holes. The point is that it comes that way by default. Many users have
no idea on how to disable them even if they know that exists. I believe
that should be disabled by default or if that removes functionality to
the browser ask the user for that. That also would be a great future
feature. What about asking the user during setup to enable/disable
that? Choose functionality/security. Looks to me like a good option.<br><br>Or what do you mean this?<br><br>// handle external links<br>// 0=default window, 1=current window/tab, 2=new window, 3=new tab in most recent window
<br>pref("browser.link.open_external", 3);<br><br>now try to tell a user to change firefox.js You call that security?<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Additionally, not sure why you want a hashed version of this flaw...</blockquote>
<div><br>
Of course you can't be sure. I wasn't talking about the bug at all. I
was talking about the browser. You got it all wrong. To be fair I
forgot to mention that I replied about firefox not about the bug, ok my
mistake. I was referring to the browser binary (Firefox). Sorry If I
mixed things a little bit however I believe you also jumped too fast.
Ok let's make this more clear so those who *could not get the point*
right away like you can get the message this time.<br>
<br>
I believe if it is digitally signed you could check that signature
after you download. Maybe is an utopia to get that for every binary you
download but I think that would be ok to get at least some things
signed. Firefox is certainly one of the most downloaded things around
and it would be great to at least call attention on that by giving the
example. The point is binaries could be modified on the fly maybe not
even by a person (could be a virus or worm in order to get inside a new
host) yet your are "downloading from a trusted website". See the
problem now?<br>
<br>
Imagine a proxy (giving you a modified version could be as easy as to
modify a cached file) or some computer that relays data gets infected
and then the malware modifies every exe that passes through that
computer. The point is that even if you follow security measures you
are at the mercy of somebody else in the middle or their mistakes
(those in the middle could be compromised, don't forget that). Should
users computers be compromised too if a server in the middle is
compromised? Think about that. So it would be great if binary
distributors sign their binaries(at least binaries). Those public keys
could be provided to people over SSL once (meaning little SSL traffic)
ensuring that nobody plays with them in the middle and gives you
another public key.<br>
<br>
I believe binary distributors do not distribute over SSL because It
simply eats too much CPU in the servers to encrypt all that data and is
also not cacheable and not compressible. But a digital signature could
be a perfect solution to that. Such signature doesn't even need to be
embedded into binaries (could be detached) and doesn't needs to be
distributed over safe channels.<br>
<br>
gpg -b -a file.exe<br>
<br>
is something really easy and fast to do by distributors<br>
<br>
and very easy to verify too by downloaders<br>
gpg -v file.exe.asc<br>
<br>
and is free software freely available to everyone too so no expensive license, works on lots of different platforms<br>
<br>
and no expensive SSL eating CPU in the servers except to download the
public keys that needs to be done only once. Systems (web applications
for example) doesn't even need to be changed since is as easy as to
provide an additional download link. A good deal in my opinion.<br>
<br>
Is very common to see downloads with a hash (MD5 SHA ...) but then the
page that offer those hashes is modifiable by means of MITM attacks. If
I download the file and somebody filters every hash like the original
(even on different websites) and provides the hash of the modified file
then we are all running ejem pretty insecure on the internet. Anyone
can generate a hash but not a signature. Now you have to trust the
distributor but also the connection provider and all the of the servers
in the middle between you and the webserver (sometimes over wireless or
satellite links and those in the middle changing all the time from
website to website). We are trusting too much. Don't you think? We also
right now can't receive a file from an untrusted source (unless of
course you get the hash over a safe channel). With a signature you
don't even need to go and get the hash.<br>
<br>
OK a simpler example so you can understand.<br>
<br>
Suppose you need a setup file from me and you have no other way to get
it (I am your ISP, a compromised server, whatever malicious thing you
can have in the middle, or simply a guy on the street, yes a guy in the street messing with your wireless thing. Remember you are
not talking directly to the datacenter backbone)<br>
<br>
Scenario 1:<br>
You say to me<br>
- Give me the file.<br>
- Ok take it (I putted a trojan inside).<br>
- Give me the hash.<br>
- Ok take It (I give you another one I generated).<br>
- Tell steve to give me his hash<br>
- Steve give me the hash (asking another webserver)<br>
- Sure<br>
- Sure steve told me that the key is this one (I tell you the very same I generated and throw away Steve's hash)<br>
<br>
Now you swallow the thing because your antivirus or anti whatever piece
of thing you could have with whatever heuristics, emulation engine,
anti metamorphic or whatever piece of technothing you pay for and
enslaves you to keep up to date could not detect it and tells you that
is safe. yet... ------> you get infected<br>
<br>
Scenario 2:<br>
- Give me the file.<br>
- Take it (I putted a trojan inside).<br>
- Give me the signature (you already have the public key from the distributor).<br>
- I don't have the signature (or I give you a another one).<br>
Then you delete the file if you don't get the signature or if the verification fails ------> you are safe<br>
<br>
Scenario 3:<br>
- Give me the file<br>
- Take it (no modification this time).<br>
- Give me the signature (you already have the public key from the distributor).<br>
- Ok take the signature.<br>
Now you verify and you can install it without doubts (note that you never needed an anti-whatever) yet.. ------> you are safe<br>
<br>
Scenario 1 is what we all usually do today when we download files from
the internet. But worse is what they tell you to do. Download only from
safe places (what is a safe place? a safe website?). Keep your
antivirus up to date etc etc. Yeahh your antivirus up to date. Until it
is face to face with a modified version of morphine or whatever
protector around covering your favorite worm.<br><br>Resuming something like this <br><br><a href="http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.5/source/firefox-2.0.0.5-source.tar.bz2.asc" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.5/source/firefox-2.0.0.5-source.tar.bz2.asc
</a> <br><br>but for binaries not only sources. And the public key visible by everyone over SSL. Today you first have to hunt for the key and the signature is only provided for the source packages.<br><br><a href="ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.5/KEY" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.5/KEY</a>. <br><br><br>FTP = Anybody can modify that in transit.<br><br>Then you can read there:<br><br><pre>Please realize that this file itself or the public key servers may be
<br><br>compromised. You are encouraged to validate the authenticity of these keys in<br>an out-of-band manner.<br><br>...<br><br>Mozilla developers: please ensure that your key is also available via the<br>PGP keyservers (such as
<br><a href="http://pgpkeys.mit.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">pgpkeys.mit.edu</a>).<br><br><br>Then after digging in <a href="http://pgpkeys.mit.edu">pgpkeys.mit.edu</a> you can finally find it here
<br><br><a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0E3606D9" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0E3606D9</a><br></pre><br>All of that comes in clear text even if you try to use SSL for <a href="http://pgp.mit.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
pgp.mit.edu</a>. Where is the security? Nowhere. The security of the world fits in a cup of coffee. Period.<br><br>
Now you could ask yourself: "Sure but why Firefox? That applies to all
sort of binaries around." Yes unfortunately it does. But then browsers are sensitive software. But
then FF is pretty popular (and growing) and should serve as an example
to others. Is open source so no problem about sharing it at all since
was made to be shared. That's why. Why not X company? Remember they are
too "superior" to even listen so I won't waste my time with them.
However I know some of them are already reading this and I hope that at least they start to consider that.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">it's not like we are passing you an executable... if you are concerned<br>that it will be modified in transit, you could always visit
<br><a href="httpS://xs-sniper.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">httpS://xs-sniper.com</a>.<br>
</blockquote><br>
Don't worry I have absolutely no intention to visit your website that
takes advantage of someone's else findings for you own advertising
profit. I can find better information about that in bugzilla. And next time save your S. You are typing extra.<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'd think SSL would provide more than<br>reasonable security around that concern.<br>
<br>If you need more, you could send me your private PGP key and I could<br>send the exploit to you directly. :)</blockquote><div><br>
Sure I can send you one of my *private* keys + public revocation
certificate (or an expired private key). But then why waste my time?
Maybe If I send you a public one you can try to play with Shor (I
recommend you to first try to understand emails or get a brain before you try
that). Remember that you need to buy a computer with 8195 qubits to run the Period finding routine. You can't do that with your Pentium X. Try your local
dealer !!<br>
<br>
Pissed off? Yes I know that last part really stinks. With that I'm
paying you with the very same coin so you can see how it looks from the other side.
The point? Don't do to others what you don't like to get back. Try that
option next time!! Take it as a lesson. And grow buddy, you are
still in the part "I'm l33t and better than everyone" the part when
you honestly look like a... (a word that you won't
properly interpret) . No offense this time.<br>
<br>
Have a nice day<br>
Waldo<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks,<br><br>Nate<br><br>On 7/25/07, wac <<a href="mailto:waldoalvarez00@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
waldoalvarez00@gmail.com</a>> wrote:<br>> Well I hope the next version won't open 45 internet explorers when I click<br>> the mailto URLs. And that when you download something you don't have the<br>> save button enabled by default (and with that delay to avoid return hits
<br>> security things) It should have enabled by default the cancel button.<br>> Instead of everybody having to wait a century to get the save button<br>> activated. Is so broken that way. Ahh and to prevent clicks the dialog
<br>> displayed somewhere away from the mouse pointer. Ahh and by default no<br>> having enabled the open with when you download but the save as (somebody can<br>> hit enter without noticing). Hey maybe configurable?
<br>><br>> And what about providing in the website some hash over SSL so you can verify<br>> that is was not modified on the fly when you download? I mean encrypting<br>> every download around is simply brain dead but a hash is OK. Hey what about
<br>> a digital signature you could verify with a public key? Zero overload on<br>> servers ;)<br>><br>> Regards<br>> Waldo Alvarez.<br>><br>> On 7/25/07, Mesut EREN <<a href="mailto:meren@basakkiremit.com.tr" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
meren@basakkiremit.com.tr</a>> wrote:<br>> ><br>> ><br>> ><br>> ><br>> > Hi all,<br>> ><br>> > FF <a href="http://2.0.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
2.0.0.5</a> new remote code Execution vulnerability, I tested FF
<a href="http://2.0.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">2.0.0.5</a> .<br>> But don't work is code.<br>> ><br>> > Example code is<br>> ><br>> > mailto:%00%00../../../../../../windows/system32/cmd".exe
<br>> ../../../../../../../../windows/system32/calc.exe " - "
<br>> blah.bat<br>> ><br>> > nntp:%00%00../../../../../../windows/system32/cmd".exe<br>> ../../../../../../../../windows/system32/calc.exe " - "<br>> blah.bat<br>> ><br>> > Where i missing?
<br>> ><br>> ><br>> ><br>> > Mesut EREN<br>> > BAŞAK ÇATI & CEPHE SİSTEMLERİ<br>> > Bilgi İşlem Sorumlusu<br>> ><br>> > MCSA:S,MCSE:S,CEH,CCNA<br>> ><br>> >
<a href="mailto:meren@basakkiremit.com.tr" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">meren@basakkiremit.com.tr</a><br>> ><br>> ><br>> ><br>> ><br>> > _______________________________________________
<br>> > Full-Disclosure - We believe in it.
<br>> > Charter:<br>> <a href="http://lists.grok.org.uk/full-disclosure-charter.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.grok.org.uk/full-disclosure-charter.html</a>
<br>> > Hosted and sponsored by Secunia - <a href="http://secunia.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://secunia.com/</a><br>> ><br>><br>><br>> _______________________________________________<br>> Full-Disclosure - We believe in it.<br>> Charter:<br>> <a href="http://lists.grok.org.uk/full-disclosure-charter.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.grok.org.uk/full-disclosure-charter.html</a><br>> Hosted and sponsored by Secunia - <a href="http://secunia.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://secunia.com/
</a><br>><br></blockquote></div><br>