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

Malware Hidden Inside JPG EXIF Headers

blog.sucuri.net

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Malware Hidden Inside JPG EXIF Headers

#61

Post by jasonlotito »

nly wrote: post #45
jasonlotito wrote: post #35

Earlier quoted context omitted.

You mean Perl, right? Because that's what PCRE is, Perl Compatible Regular Expressions, and the e modifier does in fact come from Perl.

In Perl wouldn't the /e modifier live outside the replacement string, as part of the literal regexp, and therefore out of harms way? The issue here is the "/e" modifier in PHP can be injected in to a context where the programmer didn't expect it. The preg_replace function should take the eval modifier as a flag parameter. Perl does have a ?{} eval expression, but it has to be enabled with an extra 'use' directive. Th…

> No I'm afraid it's another shoddy PHP design decision to blame here.

Please keep in mind the context of the thread. The argument wasn't the implementation, but the decision to include eval functionality in replacement functionality. Something that exists in PCRE because of Perl. So unless you want to suggest PCRE doesn't have an /e modifier that performs an eval, you aren't really adding anything to the discussion.

Re: Malware Hidden Inside JPG EXIF Headers

#62

Post by devgutt »

Dylan16807 wrote: post #60
devgutt wrote: post #55

Earlier quoted context omitted.

because eval is the real source of the problem

Would you remove the ability to load libraries, too? Because that's as dangerous as eval when it comes to purposely writing code to run external commands. The ability of a programming language to run code is not the cause of the problem, it's having domain-breaking misleading functions like a string replacer that can compile and execute.

yeah because libraries, which is available for scrutiny of a community (and you), is the same as a function that can run any arbitrary code in your program at runtime.

Re: Malware Hidden Inside JPG EXIF Headers

#63

Post by Dylan16807 »

devgutt wrote: post #62
Dylan16807 wrote: post #60

Earlier quoted context omitted.

Would you remove the ability to load libraries, too? Because that's as dangerous as eval when it comes to purposely writing code to run external commands. The ability of a programming language to run code is not the cause of the problem, it's having domain-breaking misleading functions like a string replacer that can compile and execute.

yeah because libraries, which is available for scrutiny of a community (and you), is the same as a function that can run any arbitrary code in your program at runtime.

If you can load libraries at runtime, you can load a secret malicious library, or replace a standard library with arbitrary code before triggering the loading.

So would you remove that ability to avoid its exploitation potential by malware?

Re: Malware Hidden Inside JPG EXIF Headers

#64

Post by ars »

nly wrote: post #54
ars wrote: post #48

Earlier quoted context omitted.

Cute rant. But PHP uses /e in exactly the same way: The /e is part of the literal regexp. > Contrast this to PHP, where /e appears to be on by default No, /e is not enabled by default. > and there's no mention of it whatsoever in the documentation Yah, that's because it's not on by default. Do you expect them to document every idea you make up? > is a C library... so I doubt it has any eval functionality pcre_callout…

> Cute rant. It wasn't a rant. > But PHP uses /e in exactly the same way: The /e is part of the literal regexp. PHP doesn't have literal regexps as part of the language. The regexps in PHP are string arguments to the preg_* family of functions. Perl has literal regexps. e.g. $var =~ s/$pattern/$replacement/e. If you inject "/e" in to $replacement variable, what happens? I don't know, my Perl is rusty, but I'm thinkin…

> PHP doesn't have literal regexps as part of the language.

It doesn't really change anything. Instead of using / to delimit the parts each part is sent as an argument to the function.

> Is/$pattern/$replacement/e. f you inject "/e" in to $replacement variable, what happens? I don't know

In PHP that regex would look like preg_replace("/$pattern/e", $replacement), so injecting a /e in the replacement doesn't do anything - it has to be in the pattern not in the replacement.

> Only as of 5.5. That doesn't make the decision to enable it by default in the past excusable.

No, it was never enabled by default. Why do you think it was enabled by default? That wouldn't even make sense.

> It's a callback mechanism that users of the library can use. How it's used is irrelevant, the topic at hand is PHPs behaviour.

How it's used is to - drumroll - enable /e - the callback runs the PHP function that executes the code whenever it sees a place where the /e should activate. i.e. /e is certainly part of the preg C library.

Re: Malware Hidden Inside JPG EXIF Headers

#65

Post by equiknox »

If I understand this correctly, there is PHP code (preg_replace) in the jpg exif header filled into the preg_replace function in the executable. The executable looks clean that way. The executable finds the jpg via hard-coded file path.

Seems possible that the malicious code could appear in an image itself and be flagged with a simple but distinct header. The executable could just scan display memory for the simple header and execute subsequent code when header is found. Then when a user browses the image on a website, the code is executed without hard-coding the location.

Pure speculation. Such an executable may be too visible. In any case it seems the essential problem of the preg_replace or some kind of PHP executable command would still be the red flag to find such malware.

Post reply on HN