Bonus points to Tavis Ormandy for this classy exploit code:

https://code.google.com/p/google-security-research/issues/at...

    <a href="javascript:begin()">Click Here</a> to run the command above 
    (the default will uninstall Trend Micro Maximum).

Wow I've only played with js a few days and I can interpret that pretty easily, so this seems pretty simple.

The JS is inconsequential, really. Just making the correct HTTP request, even by typing it in your browser, is the exploit.

Lol. Yes, funny how people love to throw JavaScript/Node.js into the mix.

It's like "They're using JS; how could it possibly be secure?!". That's actually highly ironic considering that JS is so far the only language that is secure enough to run universally in every browser on the planet.

People can't get around the fact that JS has evolved a LOT since it was launched and it still suffers a bad name.

You misunderstand why people think JS is insecure. The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc.

The result is that your server-side JS is more prone to different kinds of security issues.

On the client side, in the browser, JS is sandboxed, so the language is almost irrelevant. If JS can't actually access the underlying system, no number of bugs make the code insecure.

> The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc.

All those are not a factor in this instance. It seems to me it's a result of calling exec() on unscrubbed user input, and this can be done in any language.

I agree. I was responding to a tangential comment, rather than the root post.

Where here has JS been given a bad name? I didn't get that vibe.

One of those JS devs who gets really defensive when people are talking about JS and not screaming about how awesome it is.

Most of my experience saying you mostly do javascript in a room full of other coders is that they'll all scream at you to use a "better" language (on HN too).

Languages aren't inherently secure or insecure. In any case, nobody was accusing Node.js of being insecure here.

JS is not "the only language that is secure enough to run universally in every browser on the planet." In fact, JS has had many, many security issues in browsers.

Rather, JS is the only language nearly every browser on the planet has implemented in the browser (hopefully sandboxed!)

>Languages aren't inherently secure or insecure.

This is just not true.

Explain?

A language's specification can forbid you from doing things that you probably didn't intend to do. Rust is an entire language intended to be safer by design (as opposed to C, which is the cause of a lot of secure issues). You can write less safe code in Rust, but you have to tell the compiler that you're doing it on purpose.

It's also much, much easier to introduce bugs in certain languages because of the way they handle errors, or because the syntax is confusing and ambiguous. Even permissive handling of boolean logic, like what you get in PHP/JavaScript ("0" == true, for example) can result in massive security holes.

As another example, Go's := makes it much harder to do things you aren't intending to do.

Though it sounds like you're agreeing with me, that is not at all what I was saying.

Yes, I was just adding to your comment. Just pointing out that there is a pattern of people blaming JS even though it's not related at all to the problem. The same vulnerability would have existed regardless of whether the code was written in Python, Go, C, Erlang, Haskell, PHP or Scala... This is a logic error - Not something that a compiler would pick up.

In Haskell or Scala you could quite easily structure the code such that concatenating strings from different sources like that would be a compile error.

This is a massive design flaw, not a logic error. While I applaud the use of API's for modular design and communication, this is the wrong place for it.

This is clearly a terrible design flaw by Trend Micro. I hope some responsible are looking for new jobs.

Still, there isn't much faith I put in any endpoint security solutions. They are all terrible.

Bromium seems to be bucking the trend of traditional endpoint security but they have one of the worst sales / business dev programs I have ever seen. They should be much more ubiquitous than they are.

"I hope some responsible are looking for new jobs."

If they look for (and find) new jobs wouldn't that just mean the problem is diffused? Personally I would hope they learn from the experience of failing than to get punished for it.

Personally, I hope everyone else (not at Trend Micro) learns from this experience. Computer security auditing is a serious expertise, it's hard but made much harder to impossible when you don't have experts on the team and instead consider security expertise as a hobby for the qualifier.

trendmicro.com > About > "Smart, simple, security that fits"

And then second is, "a global leader in IT security" and "25 years of security expertise".

What a crock. I'm supposed to take the company's position statements and products seriously after reading this issue report? This is like finding a sponge in the body cavity of a patient. It's functionally malpractice. The CIO and CTO should be fired. The CEO probably should resign, what else is the purpose of a CEO other than to make sure the main things the company stands for are true, and actually ships products that demonstrate it stands for those things? If they don't resign the board needs to fire them.

I'd like to point out that it'd be an even bigger and redder red flag (if that's possible), should Trend Micro fire some team "security" developer, or even the product manager.

How is it possible, that a company which describes itself in the terms it has [1], have not done a thorough code review of all products before making them public? That is implicit in their own description of what their business does.

I'm not even sure the worst parts of this particular product's flaws would have escaped cursory code review by someone who is actually a security expert. And if that's true, then selling this product as it was before patching, might be fraud.

[1] http://www.trendmicro.com/cloud-content/us/pdfs/about/ds_cor...

That's a great sentiment, but sometimes we have to stick to more realistic hopes.

Those people who are responsible just received a significant education.

I don't think throwing coders or designers into a pit when they make big errors does anything helpful. Most likely, Trend has a cultural problem. Big errors like this can be an aide that spurs corrections.

The problem is that endpoint OSes are horribly insecure. It's hard to well nigh impossible to build a third party "endpoint security solution" for that, since this amounts to creating an aftermarket patch to plug a leaky dike.

There's a simple solution for that. Use a unikernel and make the entire OS immutable.

I'm really looking forward to the day where the tools are mature enough to make this an option.

I don't think it qualifies as a "simple solution" if it's not feasible with today's standards.

Simple != trivial.

A space elevator is simple. Building one is very much not trivial.

This is similar.

NodeOS is well on the way.

Packaging a server backend along with a minimal kernel and V8 VM isn't any more complicated than most of the build tools used today.

Here are the specifics: http://node-os.com/GitBlog/article.html#!200

When you cut 99% of the crap out of an OS, it becomes a lot easier to package/distribute.

Most of the work on NodeOS has to do with replacing POSIX with Javascript equivalents.

Immutable operating systems aren't a new idea either. How you think a Linux LiveCD works? ChromeOS is basically an immutable OS with an added persistence layer.

There's a lot more work to be done before any of the Unikernel implementations (ie NodeOS isn't the only one) are ready for production.

With that said, for webservers that aren't required to persist any state locally, it makes sense to remove mutability -- and there fore OS-level security vulnerabilities -- as a concern. That way, devs have more time/resources to focus on app-level security.

So this happened: https://twitter.com/shit_hn_says/status/686782891716521984

Fine for single-purpose app deployments, but on a grander scale you've just pushed all the security problems back to the APIs and interfaces of your cloud provider and/or virtualization engine. Now an AWS access token constitutes a root password for everything (for example).

Access tokens are a 'manageable' risk and AWS provides tools to enforce best practices where necessary.

Locating and regularly patching security vulnerabilities across thousands of components in a fully-featured monolithic operating system isn't. It's a potential disaster waiting to happen.

You don't need...

...a huge bundle of drivers when the OS will always run on a VM.

...extensive filesystem support when everything will be either transient or run directly from memory.

...multiple users when only one is required.

...OS-level sandboxing (ie kernel/user-space) when the VM already provides sandboxing.

...native POSIX tools when 'safe' alternatives can be run from the VM.

Despite the best intentions of developers and admins alike, the current approach to security is not working. Despite my own vigilance, I have personally had my sensitive information leaked by two separate multi-billion dollar organizations in the past year.

It's a simple fact that every feature added, increases the attack surface of the entire system. All I'm suggesting, is that it's not a bad idea to start looking to the alternatives that are becoming available.

Bingo. the PCs of old were more secure in that they did only one thing at once. These days even the most barebones install have all manner of things running in the background, and any normal user setup is likely to add a dozen more.

Pretty sure this only works on the personal version of their software. We don't even have an option to deploy a password manager (that I'm aware of) as part of the enterprise Anti-virus product.

Regardless, given what was discovered in the personal version, would you trust the enterprise version?

The personal versions are what get saddled with "Value Add-Ons" like password managers/website screening with colorful icons/blah blah bullshit bullshit. Most enterprise anti-virus software concentrates on finding viruses and maintaining compliance with whatever policies you have. They are also usually managed by different divisions with different goals.

(Whether or not anti-virus at all is effective is another debate entirely.)

I really do wonder how the market got segmented like this...

Confirmed, this does not work for `Trend Micro Worry Free Business Security` clients. I do know that the enterprise / business version installs a server on the management machine. I do not currently have access to the box that our version is hosted on to test the exploit there.

Really, it's a simple email away from a complete disaster

Send an email to several people on the organization containing the offending JS that calls shell execution, this can have a huge impact.

"Security software" LOL

While email can't directly call JavaScript, these URLs look like they'd work if just loaded, so an <img> tag might suffice to cause shell execution.

True, and you can always have a "Click here for more info" in the email pointing to a believable page.

But yeah, an image will most likely do it.

Check if your installation is vulnerable. My company uses TM Officescan for desktops and this doesn't work (I think this Password Manager is not even installed by I just tried the localhost url POC and it doesnt' work).