Aspect Security / Sonatype Study - GWT Vunlerabilities

[Geoffrey Wiseman]

This study by Aspect Security and Sonatype is making the rounds, and implies that GWT is the most-downloaded component in Maven central with security vulnerabilities:

http://www.sonatype.com/Products/Sonatype-Insight/Why-Insight/Mitigate-Security-Risks/Security-Brief

I've asked, but I'm curious which GWT vulnerabilities they might be including here.

[Geoffrey Wiseman]

The one that comes up the most in searches for me is this (relatively ancient) GWT 1.5/1.6-era RSS/XSS vulnerability:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4322

http://code.google.com/p/google-web-toolkit/issues/detail?id=3637

If they're using this one, I'm curious if their download stats only include affected versions.

[Joseph Lust]

They appear to be companies using antiquated software and GWT being called out is a bit of sensationalist cry by the authors. For example, they place in their chart "GWT" at the top, not "GWT 1.6/7." That is to say that not all GWT applications are vulnerable, just the really old, rot in place ones. They also call out SpringMVC 2.5.6, while we're rocking on 3.0.10 these days.

The gaping omission of the article is that most such Global 500 firms software development is for internal components. If at my office and most others, we don't see an internal meeting scheduling app written in GWT 1.6 to be a serious issue. However, client/external facing applications are a whole different can of beans which have many rounds of reviews before release and continuing audits. I'd estimate only 5% of our applications are externally visible, and the real number is likely lower than that.

Another omission is that many libraries are used for testing. Such libraries are consumed at compilations testing time and don't get pushed out into the production application. As such, they are much less likely to be maliciously exploited.

It's also why I constantly check for updates to core libraries and why all our POM's have a series of properties at the top such as the following so that dozens of dependencies can be upgraded in a single character change.

<spring.framework.version>3.0.7.RELEASE</spring.framework.version>

The real take away message is that Maven needs an audit feature to check your POM for known vulnerabilities, say at compile time.

Sincerely,

Joe

[Geoffrey Wiseman]

On Thursday, March 29, 2012 4:23:17 PM UTC-4, Joseph Lust wrote:

They appear to be companies using antiquated software and GWT being called out is a bit of sensationalist cry by the authors. For example, they place in their chart "GWT" at the top, not "GWT 1.6/7." That is to say that not all GWT applications are vulnerable, just the really old, rot in place ones. They also call out SpringMVC 2.5.6, while we're rocking on 3.0.10 these days.

Yeah, I wish I had more information on how they derived those numbers and what they mean. Do those numbers for GWT only include those versions that had reported vulnerabilities, and which ones? Being able to trace their chart back to specific details would be useful, because without that I'm not sure how much weight to put on their results.

 

The gaping omission of the article is that most such Global 500 firms software development is for internal components. If at my office and most others, we don't see an internal meeting scheduling app written in GWT 1.6 to be a serious issue. However, client/external facing applications are a whole different can of beans which have many rounds of reviews before release and continuing audits. I'd estimate only 5% of our applications are externally visible, and the real number is likely lower than that.

Yes, that's certainly something to consider; although ideally you wouldn't be using components with known vulnerabilities internally, the risk of doing so is somewhat lower.

 

The real take away message is that Maven needs an audit feature to check your POM for known vulnerabilities, say at compile time.

Although it's often the technology management that wants the audit features, not the individual developer -- that's why the repository-level oversight has some appeal for some organizations, I think.

  - Geoffrey