What an absolute clusterfuck. I work at a multinational company who's IT department (over my objection) installs Trend Micro on all user end points. I'll be sending this the department head's way, Trend might lose some business over this
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).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.
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.
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.
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!)
This is just not true.
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.
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'm really looking forward to the day where the tools are mature enough to make this an option.
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.
A space elevator is simple. Building one is very much not trivial.
This is similar.
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.
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.
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.
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...
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.
(Whether or not anti-virus at all is effective is another debate entirely.)
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
But yeah, an image will most likely do it.