Message-ID: <997ef2c20707271256w423e4290mbd8bb8ee8fa8ec50@mail.gmail.com>
Date: Fri, 27 Jul 2007 14:56:20 -0500
From: "Nate McFeters" <nate.mcfeters@...il.com>
To: wac <waldoalvarez00@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: FIREFOX 2.0.0.5 new vulnerability

It was a joke Waldo, relax man.  Geez people take life to seriously.  If you
noted the smiley face I put at the end of your PGP Key, you would see that I
was trying to clue you into the joke myself.  As for the rest, it seems like
that is a coment for Mozilla and not for me; however, you original email was
not very clear in that.

Relax it back man, it's almost time for Vegas... don't take every joking
email you get so seriously, it could be bad for your health in the long run.

Nate

On 7/27/07, wac <waldoalvarez00@...il.com> wrote:
>
> Hi Nate:
>
> On 7/25/07, Nate McFeters <nate.mcfeters@...il.com > wrote:
> >
> > Hey Waldo,
> >
> > As always with exploits, it's difficult to predict how they will
> > interact in every environment they may be accessed in.
>
>
> 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).
>
> MFSA 2007-25<http://www.mozilla.org/security/announce/2007/mfsa2007-25.html>XPCNativeWrapper pollution
> MFSA 2007-24<http://www.mozilla.org/security/announce/2007/mfsa2007-24.html>Unauthorized access to wyciwyg:// documents
> MFSA 2007-23<http://www.mozilla.org/security/announce/2007/mfsa2007-23.html>Remote code execution by launching Firefox from Internet Explorer
> MFSA 2007-22<http://www.mozilla.org/security/announce/2007/mfsa2007-22.html>File type confusion due to %00 in name
> MFSA 2007-21<http://www.mozilla.org/security/announce/2007/mfsa2007-21.html>Privilege escalation using an event handler attached to an element not in
> the document
> MFSA 2007-20<http://www.mozilla.org/security/announce/2007/mfsa2007-20.html>Frame spoofing while window is loading
> MFSA 2007-19<http://www.mozilla.org/security/announce/2007/mfsa2007-19.html>XSS using addEventListener and setTimeout
> MFSA 2007-18<http://www.mozilla.org/security/announce/2007/mfsa2007-18.html>Crashes with evidence of memory corruption
>
> I have 2.0.0.4 here and I'll wait for 2.0.0.6 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 2.0.0.5 out of 2.0.0.1 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).
>
> I'm sure the bug is there because on 2.0.0.4 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, 2.0.0.1 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.
>
>
> If you have
> > launch external URI's on by default, the tab issue will come up;
> > however, the exploit should still occur.
> >
>
>
>
>
>   I'd recommend turning off
> > the launch external URI's feature for your own safety though.
>
>
> 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.
>
> 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.
>
> Or what do you mean this?
>
> // handle external links
> // 0=default window, 1=current window/tab, 2=new window, 3=new tab in most
> recent window
> pref("browser.link.open_external", 3);
>
> now try to tell a user to change firefox.js You call that security?
>
>
> Additionally, not sure why you want a hashed version of this flaw...
>
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> gpg -b -a file.exe
>
> is something really easy and fast to do by distributors
>
> and very easy to verify too by downloaders
> gpg -v file.exe.asc
>
> and is free software freely available to everyone too so no expensive
> license, works on lots of different platforms
>
> 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.
>
> 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.
>
> OK a simpler example so you can understand.
>
> 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)
>
> Scenario 1:
> You say to me
> - Give me the file.
> - Ok take it (I putted a trojan inside).
> - Give me the hash.
> - Ok take It (I give you another one I generated).
> - Tell steve to give me his hash
> - Steve give me the hash (asking another webserver)
> - Sure
> - Sure steve told me that the key is this one (I tell you the very same I
> generated and throw away Steve's hash)
>
> 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
>
> Scenario 2:
> - Give me the file.
> - Take it (I putted a trojan inside).
> - Give me the signature (you already have the public key from the
> distributor).
> - I don't have the signature (or I give you a another one).
> Then you delete the file if you don't get the signature or if the
> verification fails ------> you are safe
>
> Scenario 3:
> - Give me the file
> - Take it (no modification this time).
> - Give me the signature (you already have the public key from the
> distributor).
> - Ok take the signature.
> Now you verify and you can install it without doubts (note that you never
> needed an anti-whatever) yet.. ------> you are safe
>
> 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.
>
> Resuming something like this
>
> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.5/source/firefox-2.0.0.5-source.tar.bz2.asc
>
>
> 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.
>
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.5/KEY.
>
>
> FTP = Anybody can modify that in transit.
>
> Then you can read there:
>
> Please realize that this file itself or the public key servers may be
>
> compromised.  You are encouraged to validate the authenticity of these keys in
> an out-of-band manner.
>
> ...
>
> Mozilla developers: please ensure that your key is also available via the
> PGP keyservers (such as
> pgpkeys.mit.edu).
>
>
> Then after digging in pgpkeys.mit.edu you can finally find it here
>
>
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0E3606D9
>
>
> All of that comes in clear text even if you try to use SSL for pgp.mit.edu.
> Where is the security? Nowhere. The security of the world fits in a cup of
> coffee. Period.
>
> 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.
>
>
>
> > it's not like we are passing you an executable... if you are concerned
> > that it will be modified in transit, you could always visit
> > httpS://xs-sniper.com <https://xs-sniper.com/>.
> >
>
> 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.
>
> I'd think SSL would provide more than
> > reasonable security around that concern.
> >
> > If you need more, you could send me your private PGP key and I could
> > send the exploit to you directly. :)
>
>
> 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 !!
>
> 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.
>
> Have a nice day
> Waldo
>
>
> Thanks,
> >
> > Nate
> >
> > On 7/25/07, wac < waldoalvarez00@...il.com> wrote:
> > > Well I hope the next version won't open 45 internet explorers when I
> > click
> > > the mailto URLs. And that when you download something you don't have
> > the
> > > save button enabled by default (and with that delay to avoid return
> > hits
> > > security things) It should have enabled by default the cancel button.
> > > Instead of everybody having to wait a century to get the save button
> > > activated. Is so broken that way. Ahh and to prevent clicks the dialog
> >
> > > displayed somewhere away from the mouse pointer. Ahh and by default no
> > > having enabled the open with when you download but the save as
> > (somebody can
> > > hit enter without noticing). Hey maybe configurable?
> > >
> > > And what about providing in the website some hash over SSL so you can
> > verify
> > > that is was not modified on the fly when you download? I mean
> > encrypting
> > > every download around is simply brain dead but a hash is OK. Hey what
> > about
> > > a digital signature you could verify with a public key? Zero overload
> > on
> > > servers ;)
> > >
> > > Regards
> > > Waldo Alvarez.
> > >
> > > On 7/25/07, Mesut EREN < meren@...akkiremit.com.tr> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > FF 2.0.0.5 new remote code Execution vulnerability, I tested FF
> > 2.0.0.5 .
> > > But don't work is code.
> > > >
> > > > Example code is
> > > >
> > > > mailto:%00%00../../../../../../windows/system32/cmd".exe
> > > ../../../../../../../../windows/system32/calc.exe " - "
> > > blah.bat
> > > >
> > > > nntp:%00%00../../../../../../windows/system32/cmd".exe
> > > ../../../../../../../../windows/system32/calc.exe " - "
> > > blah.bat
> > > >
> > > > Where i missing?
> > > >
> > > >
> > > >
> > > > Mesut EREN
> > > > BAŞAK ÇATI & CEPHE SİSTEMLERİ
> > > > Bilgi İşlem Sorumlusu
> > > >
> > > > MCSA:S,MCSE:S,CEH,CCNA
> > > >
> > > > meren@...akkiremit.com.tr
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Full-Disclosure - We believe in it.
> > > > Charter:
> > > http://lists.grok.org.uk/full-disclosure-charter.html
> > > > Hosted and sponsored by Secunia - http://secunia.com/
> > > >
> > >
> > >
> > > _______________________________________________
> > > Full-Disclosure - We believe in it.
> > > Charter:
> > > http://lists.grok.org.uk/full-disclosure-charter.html
> > > Hosted and sponsored by Secunia - http://secunia.com/
> > >
> >
>
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists