Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we broke PHP, hacked Pornhub and earned $20k

evonide.com

Post reply on HN
Print view View original

41–50 of 107 posts

Re: How we broke PHP, hacked Pornhub and earned $20k

#41

Post by segmondy »

krapp wrote: post #8

The takeway: You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.

Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.

Re: How we broke PHP, hacked Pornhub and earned $20k

#42

Post by underwater »

segmondy wrote: post #41
krapp wrote: post #8

The takeway: You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.

Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.

That's not actionable. You have to deal with user input at some point.

What if my language can't deal with strings properly? Maybe strpos has a buffer overflow on a carefully crafted input. Would I be wrong for using it?

Re: How we broke PHP, hacked Pornhub and earned $20k

#44

Post by eropple »

cocotino wrote: post #34
smt88 wrote: post #28

Earlier quoted context omitted.

It depends on the code base and use case. For the vast majority of coders, the time/cost savings will be in the usability of the language itself rather than the hardware required to run the code.

Sure, tell that to Reddit.

I'm very curious how you went from "the vast majority of coders" to "tell that to Reddit".

Re: How we broke PHP, hacked Pornhub and earned $20k

#45

Post by Scaevolus »

justinlardinois wrote: post #32
nickpsecurity wrote: post #29

Earlier quoted context omitted.

Dude, that's horrific. I figured some secure coders wouldve at least implemented a better JSON one by now since it's relatively simple. Or are they already available but dev's often rely on these broken ones?

Hash functions designed for hash tables are generally not hard to find collisions for, so there's not much that can be done. You could shoehorn in a secure hash function, but that would hurt performance.

Having per-table random seeds and properly designed hash function prevents remotely forced collisions. This is the typical defense against hashtable DOS.

It has to be done properly, of course -- for example, a poorly designed hash function could have characteristic collisions for many different seeds.

Re: How we broke PHP, hacked Pornhub and earned $20k

#46

Post by JeremyBanks »

justinlardinois wrote: post #32
nickpsecurity wrote: post #29

Earlier quoted context omitted.

Dude, that's horrific. I figured some secure coders wouldve at least implemented a better JSON one by now since it's relatively simple. Or are they already available but dev's often rely on these broken ones?

Hash functions designed for hash tables are generally not hard to find collisions for, so there's not much that can be done. You could shoehorn in a secure hash function, but that would hurt performance.

I think that most major languages have fixed this for years.

Python in 2012: http://bugs.python.org/issue13703

Re: How we broke PHP, hacked Pornhub and earned $20k

#49

Post by toast0 »

underwater wrote: post #42
segmondy wrote: post #41

Earlier quoted context omitted.

Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.

That's not actionable. You have to deal with user input at some point. What if my language can't deal with strings properly? Maybe strpos has a buffer overflow on a carefully crafted input. Would I be wrong for using it?

Never trust user input doesn't mean never use user input; you need to use it carefully -- often that means restricting to acceptable values and lengths, (appropriate!) escaping, and passing through that it's user input to other functions (ex: sql placeholders). When functions do arcane things, and don't let you pass through that it's user provided, that's a red flag.

Note that a cookie that you set, and are now getting back IS user-input, unless you do something to validate that it's actually the value you set. (HMAC is a good start)

If your language can't deal with strings properly, I strongly suggest you not expose it to strings provided by users. If you do expose it to strings from users, at least you should sandbox your application as much as possible.

Re: How we broke PHP, hacked Pornhub and earned $20k

#50

Post by tjallingt »

I have some questions about two things in the exploit code that puzzled me:

  my $php_code = 'eval(\'
     header("X-Accel-Buffering: no");
     header("Content-Encoding: none");
     header("Connection: close");
     error_reporting(0);
     echo file_get_contents("/etc/passwd");
     ob_end_flush();
     ob_flush();
     flush();
  \');';
1. they seem to be using php to code the exploit (solely based on the $ before the variable name) but i've never seen the 'my' keyword before, what exactly is this language?

2. if i understand the exploit correctly they got remote code execution by finding the pointer to 'zend_eval_string' and then feeding the above code into it. doesn't that mean the use of 'eval' in the code that is being executed is unnecessary?

Post reply on HN