Message-ID: <BAY133-DS15D3F4A17EFC351DFEEDCF82B0@phx.gbl>
Date: Tue, 12 Feb 2008 18:40:09 +0200
From: "Dror" <dror@...grp.com>
To: "Dror" <dror@...grp.com>
Subject: FaceBook ImageUploader4.1.OCX Stack Buffer
	Overflow Vulnerability

FaceBook ImageUploader4.1.OCX Stack Buffer Overflow Vulnerability

Release Date:
Feb 11, 2008

Date Reported:
Dec 23, 2007

Severity:
High (Remote Code Execution)

Vendor:
FaceBook (originally Aurigma)

Systems Affected:
FaceBook Image Uploader 5.0.14.0 and earlier (Microsoft Windows only)


Overview:
FaceBook is the world's largest Social Network. It has about 60 million
users.
MC Group has discovered a critical vulnerability in FaceBook's Image
Uploader.
The vulnerability allows a remote attacker to reliably overwrite the entire
stack,
overwriting the SEH handler and to execute arbitrary code in the context of
the user
who executed Internet Explorer.


Technical Details:
When assigning a value to any string type attribute of the ImageUploader
class,
the value is copied into a fixed size buffer on the stack. As there is no
length
validation imposed prior to the copying function, the stack-based buffer can
be
overflowed by whatever is passed into the attribute.

The "ImageUploader4.1.OCX" module is compiled with the "/GS" flag, therefore
there
is a security cookie protection. This protection can be bypassed by
overwriting the
SEH handler.

On XP SP2 systems, *Almost* all modules used by Internet Explorer are
compiled
with SafeSEH, therefore to exploit the vulnerability an unsecured module
must
be used, such as LPK.DLL. It is also possible to bypass the protection of
systems
with non executable stack by using the classic return to libc method
returning
into VirtualProtect.

To achieve exploitation across all versions of windows, it is possible to
"Spray"
the heap and jump to a constant chosen address. Using this method an
attacker will
not execute code on systems with Software DEP enabled on iexplore.exe.

Work Around:
To work around this vulnerability, if you are not actively using FaceBook's
Image Uploader you can execute the command-line to uninstall the ActiveX:
"regsvr32 /u %windir%\downlo~1\ImageUploader4.1.OCX"
Or by turning on the KillBit at (so the ActiveX cannot be created under
Internet Explorer)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\
{5C6698D9-7BE4-4122-8EC5-291D84DBD4A0}
"Compatibility Flags"=DWORD:0x400

By Un-Registering this ActiveX, Uploading files to FaceBook using the Image
Uploader
will not be possible, thereby mitigation this vulnerability.

Proof Of Concept:
http://www.Mc-Grp.biz/security/facebook/poc.htm

One of FaceBook's initial responses:
"We received your demo, and we've been working with an outside vendor to
confirm
the results. Going forward, please communicate exclusively with myself or
our
security team regarding these findings."

One of FaceBook's last responses:
"Your report has been taken seriously, we are currently working with an
outside
vendor to address the issue. We do appreciate that you have reported this
into us,
however the issue is taking longer to address than expected from our
vendor."

Vendor Status:
FaceBook has released a patch for this vulnerability. We had not been
notified.
Unfortunately the ActiveX doesn't have an "Auto Update" mechanism and
therefore
the vulnerability, will NOT be automatically fixed for the users. There is a
better
solution in which the owner of the domain which uses this ActiveX will add
code for
installation of the NEW FIXED ACTIVEX at the MAIN PAGE.
For Example: if I am a FaceBook user and I uploaded my images and the next
time I
will upload another image is in 3 month, I will be vulnerable for the next 3
months!!!

The patch is available at (FaceBook, user must be logged in and create an
album):
http://www.facebook.com/editalbum.php?aid=<user_album_id>&add=1

Extra Details:
Aurigma has sold this product to more than 131 companies around the world.
The most common way they deploy this product is by giving it a new title and
a new
UNIQE CLASSID and recompile it for each of their clients. This means that
each
"client" of all companies in this list is VULNERABLE and should demand that
Aurigma create and APPLY A FIX for their version of the product.
If we make a rough estimation: in the worst case every company on the list
has
managed to attract 1000 surfers that have installed the ActiveX to upload
images,
this would make 131 * 1000 = 131,000 VULNERABLE computers. This of course is
probably
an unrealistic estimate and the actual numbers are much greater!  And if you
take into
consideration that some of the companies on the list are very successful and
have
attracted millions of clients, it is clear that the number of vulnerable
users is HUGE!
For a list of the large companies in terms of number of users:
facebook.com
myspace.com
slide.com
ancestry.com
hevre.co.il
mekusharim.co.il
tapuz.co.il
foto.com
kodakimages.com
mail.ru
mypix.com
online.de
http://www.Mc-Grp.biz/security/facebook/VulnerableDomains.txt

Time Line:
12/31/2007 Initial vendor notification
01/03/2008 MC calls FaceBook to ask what's going on?
01/03/2008 FaceBook says: ".I have forwarded your message to others within
our
	   organization so they can investigate."
01/08/2008 MC communicates with FaceBook telling them: "We have not heard
from
	   you since last week!"
01/08/2008 FaceBook reply that ".based on all the communication i have seen
from
	   you guys thus far, i am unaware of the specific vulnerability you
are
	   concerned about."
01/09/2008 MC replies: ".We are willing to discuss all this and also talk
about a
	   solution which we have conceived. I do not know your position in
the
	   organization and I think this vulnerability deserves the
attention of a
	   "C level individual. I ask that someone on the appropriate level
contact
	   me about all this (office or mobile)."
01/09/2008 FaceBook replies: ".This was just passed along to me today, I'm
interested
	   in hearing what you found. Could you please be more specific
about your
	   findings?"
01/11/2008 MC replies: "Why don't we set up a conference call for sometime
later
	   today?! When is a good time for you?"
01/11/2008 FaceBook rejects MC's proposal: ".It will be for the best if we
continue
	   communication over email because of the time difference. If it's
alright
	   with you, could you continue on with what you found?"
MC replies: ".If you want to do this through email please send me your PGP
Public Key
	   so we can send you a proper encrypted email."
01/14/2008 MC sends FaceBook the encrypted demonstration: ".Attached is the
information.
	   For more help from us please contact us."
01/15/2008 MC asks FaceBook: "Please update me". 
	   Face Book return with: ".We're noticing that parameters sent to
the software
	   are length checked and forced to be integers. Do you have a proof
of concept
	   to better display the vulnerability?"
01/16/2008 MC replies with: "The POC (Proof Of Concept=demonstration) is
statistic, so
	   it works between the first test to the 10th  run (it can be made
to work
	   almost 100% on all windows versions but we did not go to the
trouble of doing
	   all that work). The length of assignment of string type
attributes is not
	   checked! Attached is a demonstration that will execute the
windows calculator
	   on your computer (if windows XP, SP2 Professional). Please
update."
01/22/2008 MC gets anxious and send FaceBook the following message: "Dear
Facebook
	   management, Have not heard back from you, although I have left
messages for
	   you. We would like to know that you are dealing with this
situation because,
	   as you know, the danger to your users is immediate and the damage
could be
	   extensive. What is going on?" 
	   FaceBook responds with: ".We received your demo, and we've been
working with
	   an outside vendor to confirm the results. Going forward, please
communicate
	   exclusively with myself or our security team regarding these
findings."
	   And MC tells FaceBook that: ".When you say speed up the process
what do you
	   mean? If you're looking for a "cure" - we know what needs to be
done and can
	   help you."
01/29/2008 MC loses its patients and lets FaceBook know that: ".I have not
heard a word
	   from you since my email to you a week ago! Therefore, I will not
limit myself
	   from communicating only with you or your security team, as you
requested!
	   .Facebook is not taking this seriously and you do not appreciate
our help
	   which was offered without any demands whatsoever! We said we are
not asking
	   for anything from Facebook ... As you are well aware, a month has
passed from
	   our initial correspondence to Facebook and our patience and
goodwill have been
	   drained."
	   The following day (01/30) MC got this note from FaceBook: ".Your
report has
	   been taken seriously, we are currently working with an outside
vendor to
	   address the issue. We do appreciate that you have reported this
into us,
	   however the issue is taking longer to address than expected from
our vendor.
	   We are pressuring them with how important this issue is, not only
from our
	   viewpoint but from yours. We will provide you with an update
about the
	   software when one is available.
	   And MC replied with: ".As I wrote to you before, why don't you
talk to OUR
	   people - they can help you with this issue and also with a
solution?!"
02/04/2008 MC sent yet another inquiry: ".I hope to get an update from you
sometime today. I don't know why you decided to NOT take my offer regarding
talking to our people about this. I think this will save you time and money!
The offer still stands."
	   The next day we got this: ".I appreciate your efforts to report
this issue
	   to us. For future reports, we may consider bringing in an outside
consultant.
	   In this case it has made more sense to work directly with the
vendor that
	   supplied the software."
02/09/2008 MC wrote that: ".We have seen that you put out a new release that
is supposed
	   to fix the problem that we have been talking about."
02/11/2008 MC has not heard from FaceBook since February 5th!



Credit:
Rafel Ivgi, "The-Insider"

Greetings:
xbxice (thx a lot!!!), the_pull, Dror Shalev, Aviv Raff, pedram, Noam
Rathaus, dr. T

Copyright (c) 2006-2008 MC Group Ltd.
Permission is hereby granted for the redistribution of this alert
electronically.
It is not to be edited in any way without express prior consent of MC Group.
If you wish to reprint all or any part of this alert in any other medium
excluding
electronic medium, please email Office@...grp.com for permission.

Disclaimer
The information within this paper may change without notice.  Use of
this information constitutes acceptance for use in an AS IS condition.
There are no warranties, implied or express, with regard to this
information.  In no event shall the author be liable for any direct or
indirect damages whatsoever arising out of or in connection with the use
or spread of this information.  Any use of this information is at the
user's own risk.

Feedback: 
Please send suggestions, updates, and comments to: 
MC Group Ltd.
http://www.MC-Grp.com                  office@...Grp.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/

Powered by blists - more mailing lists