lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Jul 2007 15:13:20 -0400
From: wac <waldoalvarez00@...il.com>
To: "Nate McFeters" <nate.mcfeters@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: FIREFOX 2.0.0.5 new vulnerability

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.
>

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ