Hacker News Reader

Comment by kaerast | Hacker News Reader

You mean like the exploit scanner as linked to from the source article? Make that part of core WordPress and scan for other obfuscation techniques too and you're well on the way to improving things.

View on HN

No, that means you'll be well on the way of improving the obfuscation techniques.

Scanning a piece of code to try and decide if it is "malicious" or not is essentially the halting problem, which is impossible to solve. As long as you have a system where you install third-party code you are screwed, no matter what the base language is.

That doesn't mean it's totally pointless to look for blatant exploits. A lot of script kiddies are going to use naive and obvious methods that can be caught with simple automated scans. While this method may not catch 100% of occurrences, it can certainly help.

Well, that depends on your point of view. My personal opinion is that such a system would give people a false sense of security (since we know it's impossible for such a system to detect all malicious content) and would cause "script kiddies" a few minutes of annoyance as they make the tiny tweaks necessary to evade the filter. It would also drain development effort away from the main Wordpress system.

As long as the system doesn't make extravagant claims there shouldn't be a problem. A message on each page of the scanner like "This is only a precautionary measure that checks for known exploits; there can still be malicious code in any third-party code. Only use themes or plugins from sources you know to be safe." should not give a false sense of security, but can still help things.

Anti-virus and anti-spam applications can never be 100% effective either, but we use those because they're useful on occasions where they do work. Should we give those up altogether because, since the virus writers merely have to look up circumvention techniques, it's a waste of programmer time?

For Wordpress themes as they are currently implemented, this is true, but the concept of being able to decide whether a given piece of code will do specific things is known as sandboxing and has many real-world implementations. You can be relatively certain that code running in specific sandboxes will not perform specific actions. You can be relatively certain, for example that an unsigned Java applet won't transmit data over a network to a third party.

It wouldn't be hard to design an HTML templating system that would never render the string "<script", to provide an overly simple example. Making such a system popular enough that malicious themes are an issue worth worrying about is left as an exercise for the reader.

Reply on news.ycombinator.com