exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

facebookadv-overflow.txt

facebookadv-overflow.txt
Posted Feb 12, 2008
Authored by Rafel Ivgi | Site mc-grp.com

Facebook Image Uploader versions 5.0.14.0 and below suffer from a stack buffer overflow vulnerability.

tags | advisory, overflow
SHA-256 | 6152aa9c19bfdd72791f98dfb5833a168d8504603ca4d7435002e4d4abb45373

facebookadv-overflow.txt

Change Mirror Download
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@mc-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@Mc-Grp.com
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close