Feeds

back to article Java open-source frameworks 'pose risk' to biz - report

Open-source programming frameworks revolutionised Java development during the last decade, but not enough people know how to use them properly. That’s according to the CRASH Special Report by CAST that sampled 496 applications with 152 million lines of code and found most apps had been misconfigured. This increased the degree of …

COMMENTS

This topic is closed for new posts.
FAIL

If they contain the following in any java applet:

AverageRangeStatisticImpl its got an RCE.

Method Handle its got an RCE.

Thats not a misconfiguration, thats a 'security risk by code'. *applauds this so-called revolution*

0
4
Anonymous Coward

You don't understand the recent vulnerability reports.

That's not how it works, not even close. Those methods can be exploited if you can send code that invokes them in a particular fashion to be executed on the host, such as when java is enabled in the browser, but a desktop application that use them isn't necessarily even network-connected, and won't be invoking them in the bad context that is required to bypass security even if it is. It's not like a buffer overflow where you can simply send them some bad data; you have to be running your own code on the host already, as the exploit only lets you get out of the security sandbox.

I'm afraid your FAIL icon applies only to yourself.

6
0
Silver badge

Re: You don't understand the recent vulnerability reports.

I agree that acting on untrusted data is the prime concern here and nothing to do with the commands used, but I think the OP's point is that you can quite easily end up using quite complex commands that have knock-on effects that you may not even realise. Both are a concern, and both shouldn't be present in production code without suitable testing. But without KNOWING that X involves Y, especially if it's not obvious, someone could easily use those on untrusted data thinking they are "safe". Like gets() or sprintf() - fine if you KNOW their limits and dangers, but if you don't it's easy to do silly things that can cause you lots of trouble.

3
0
WTF?

Re: You don't understand the recent vulnerability reports.

GIven how layered attacking apparently works, if it cant jump out of a sandbox.. it cant jump into a fire?

indeed buffer overflows are a relatively separate method. But you knew all this, right?

0
0
Bronze badge

Re: You don't understand the recent vulnerability reports.

I agree that acting on untrusted data is the prime concern here

No, the issue with the recent Java applet container vulnerabilities is that the sandbox is broken, and applets can gain access to privileged methods. It's not a matter of "untrusted data" at all; the applet container is intended for running untrusted code, and it's not a "data" issue except in the Von Neumann sense of the code-data equivalence.

Both are a concern, and both shouldn't be present in production code without suitable testing.

The recent applet container vulnerabilities don't require using the affected methods in "production code". And in these cases it's the attacker that controls the code anyway.

Like gets() or sprintf() - fine if you KNOW their limits and dangers

gets() is never "fine". It's a vulnerability unless you have complete control over the input, and since it has a trivial safe replacement, there is absolutely no reason to use it. Ever.

0
0
Bronze badge

Re: You don't understand the recent vulnerability reports.

GIven how layered attacking apparently works, if it cant jump out of a sandbox.. it cant jump into a fire?

indeed buffer overflows are a relatively separate method. But you knew all this, right?

This post is largely meaningless and irrelevant. There's no "sandbox" involved with the type of applications the article is discussing (unless the application makes use of its own security context), and the exploits recently published by Adam Gowdiak and the folks at Security Explorations aren't applicable to them. Those exploits involve executing code supplied by an attacker.[1] Nor are buffer overflows (perhaps an incoherent reference to Lee Dowling's post?) in any way relevant.

Face it: your original post was a technically incorrect, vague, confused argument about an issue unrelated to the actual content of the article. Lee Dowling attempted to find some relevance by drawing an analogy, but it was rather strained (and still technically incorrect in key points). The AC (sigh) who replied initially was spot-on. Trying to defend your position now just makes you look silly.

But you knew this, right?

[1] See for example http://www.security-explorations.com/en/SE-2012-01-details.html. Of course anyone commenting about these recent exploits has no doubt read the research. No doubt.

1
0
Bronze badge

Re: You don't understand the recent vulnerability reports.

Following up on my own posts in this thread: Today Security Explorations released another (impressively lengthy) bulletin describing additional vulnerabilities. Among them is a description of successfully attacking a Java RMI server remotely.[1]

Now, it would clearly by marvelously foolish to have an RMI server open on the Internet; but marvelous foolishness is hardly unknown. And it's conceivable that this vector might be open to an inside attacker who does not have an easier one. In any case, the Security Explorations / Gowdiak vulnerabilities are no longer solely an issue for applets.[2]

[1] SE mention the MBeanInstantiator bug, known to be exploited in the wild, and their own "Issue 50" (a way to violate Java type safety by exploiting a bug in the Java CORBA deserializer) and "Issue 52" (MBean's Introspector can be hijacked to invoke any no-argument method), as exploitable over RMI.

[2] The new SE bulletin argues that any security vulnerability in Java SE is a problem for Java SE in all environments, unless an attacker has no way to deploy hostile code to the environment. But this is circular reasoning; if an attacker can update your production systems, then you have worse problems than Java flaws. What's important about the work SE have done over the past year is that they've revealed numerous security holes in the environment where an attacker can easily deploy hostile code - the browser.

0
0

This post has been deleted by its author

Bronze badge
Trollface

Post hoc ergo propter hoc

Right. So I should just throwing in .Net code in a Java project and magically watch the quality increase?

Did those code gazers bother to do any analysis on *why* these differences occur or is our Reg hack in question too lazy to quote them?

6
1
Happy

Re: Post hoc ergo propter hoc

If you’ve mixed Java & .NET, you’ve implemented your data model in two languages and are more likely to have modelled & then generated it; you’re also likely to have structured the separation of server & client logic (e.g. .NET WPF client, JEE server).. its all that thinking & designing that adds the quality.

1
0

This post has been deleted by its author

Frameworks make life more complicated without any real advantage - IMHO

I had to use the abomination which is Spring together with Hibernate for almost 1 year ( then I just resigned because I was tired of developing using complicated XML prayers instead of proper java with real time syntax checks instead of at runtime as it happens with Spring )

Configuring a simple mapping table for a many to many relationship between two others is something that can take forever. A simple select query can be executed as a set of different ones and I read in somebody's post it once included an update statement for no reason. HQL, an aborted version of SQL, is not as easy to use. If you want to use an annotation for the where clause, they created a @Where one. Why? WHy? WHY!

Spring is the reinvention of the wheel, but triangular and made of glitter plated turds instead of the round rubber original one. Never figured out what it is that it does which can't be done faster, and more easily, in Java. Maybe it's just me, but from what I saw in the blogs online, I don't think it's the case.

If they are so fantastic and I am plain wrong, I can't explain why a big project, but quite straight forwars, kept on missing every possible headline ever, to the point of panic for the best part of it before I left.

8
6
Meh

Re: Frameworks make life more complicated without any real advantage - IMHO

Sorry, but I believe it's you.

Spring (and Hibernate) is not "reinventing the wheel", in most cases it's perfectly capable of using whatever previous invention you feel comfortable with. You don't like annotations? Use XML configuration instead. Or create a simple POJO that sets up your beans with plain Java code. You hate HQL? Most queries can be nicely done with the Criteria API as well, and there's no shame in using JdbcTemplate if everything else fails. (For some tasks, such as mass inserts, using Hibernate itself may be unnecessary.) You hate Hibernate altogether? Spring works with all major ORM frameworks.

Some training can help, yes. Although I have to say, there were only a handful of cases when I couldn't find an answer to my question with a couple of Google searches, so even those (insanely expensive) Spring courses aren't 100% necessary to properly work with the framework.

3
4

Re: Frameworks make life more complicated without any real advantage - IMHO

tldr version: you're doing it wrong.

Spring is a large framework and provides many nooses with which to hang yourself.

Taking one small part of your rant, the ORM bit, there are several programming models for querying within Spring/Hibernate, including Criteria queries, HQL, pure native SQL, and a sort of HQL-SQL hybrid which allows you to use entity syntax within an SQL query. Each of them has strengths and weaknesses.

1
0
Anonymous Coward

Re: Frameworks make life more complicated without any real advantage - IMHO

Have an upvote - I agree with you in general about Frameworks - to constraining, by definition really. And XML is not a goddamn programming language! It's good for data serialization or transforming from one XML format to another, à la XSLT, and that's it.

4
1
Silver badge

Spring/Hibernate is reinventing the wheel

Actually, it is a reinvention of the wheel. J2EE already existed, as a framework, and does most of the stuff Spring and Hibernate does. Some folks just got mad that Entity Beans were chosen for ORM mapping, then went on and built the "renegade" framework. The EE5 spec now uses annotations, threw away the original EntityBean and now uses something closer to Hibernate (IIRC Hibernate can be used as the persistence engine). Upshot of using EE5+JSF w/o extras is that resulting EARs can be deployed to appservers without munging with extra libs or XML config files on the appserver...

6
0

Big News - Software Quality Varies!

I suspect the quality has little (probably not zero) to do with the framework chosen and more to do with whether the team - from management on down but especially management - know what they're doing. You can look at almost any type of software project (and other types too) and you're going to find a range of qualities.

Regarding the additional languages used I think they're confounding cause and effect: the more capable teams do this at least tolerably well; most other don't even try or try and then rapidly give up on the idea when they find they don't have the required skills and can't make it work.

4
0

Re: Big News - Software Quality Varies!

"I suspect the quality has little (probably not zero) to do with the framework chosen and more to do with whether the team - from management on down but especially management - know what they're doing."

Agree completely - even by El Regs low standards this is a piss awful bit of 'reporting'.

0
0
Bronze badge

So using a framework doesn't automatically make code good?

Well there's a surprise.

4
0
Silver badge
Facepalm

Enhanced knowledge!

People use frameworks, or they don't. This may increase risk or lower risk. Misconfiguration may play a role. Conclusions can or cannot be drawn, and any conclusion drawn may be due to sampling, preselection, look-elsewhere effects or lousy stats.

Next: Activities of bears in woods.

5
0
Silver badge
Joke

@Destroy

"Next: Activities of bears in woods."

And we all know they're going to check out Yellowstone park first to see if the takeoff is real :-)

0
0

different JNI

"without any mingling of difference languages, also scored highly on quality."

You mean 'different'.

On the other hand, is the output of 'diff -e' a difference language?

"Mixing Java with C or C++ lowered the score"

JNI - like being a blind brain surgeon using barbecue tongs.

Beats me how CAST can analyse that for quality.

2
0
Anonymous Coward

How the hell is this specific to applications using open source frameworks? Having had to completely rewrite applications that were written using proprietary frameworks, I'd expect them to have more bugs than ones using better documented open source frameworks such as Hibernate or Spring.

3
0
Happy

headline

Java 'pose risk' to biz - report

There, fixed it for you.

1
1

fingers in ears

La la la la la la

AbstractSingletonProxyFactoryBean

lalalalalala

2
0
Bronze badge

Flies in the face of the "programmers are interchangeable" principle

"The common link is the framework, and knowing how to use it properly."

Which would mean proper training plus proper pay and benefits.

But top management would rather temporarily boost profits by going cheap and poorly trained.

0
0
Anonymous Coward

Scare mongering to sell a 'security' testing process.

All that is really required is for developers to learn about and be conscious of possible exploits, and to code defensively to block them e.g. consider best practice authentication and security, always bounds and validity check values and data, use robust API like PrepareStatements where possible, properly escape data for raw SQL, XML, Json, Javascript, etc., don't just append text to strings like an idiot. I saw way too much unsafe unescaped junk, from experienced developers who should know better, but naively assumed they control the source of input data!

I don't want to hear about IoC abstractions like Spring, they can ironically make development more complicated and less secure. JEE is dated klunky junk, as are a number of heavy weight frameworks, and I prefer MyBatis to Hybernate.

0
0
Holmes

Frameworks

I don't do java professionally.

But i have used frameworks in other languages and particular in open source languages like PHP where i would say the framework world is alot more wild west !

All frameworks have their limitations but also all frameworks need particular knowledge of that framework, usually gained by experience.

People learn some of their day to day knowledge from training and education but more on the job from more experienced people.

This story is about a failing in people, frameworks are a distraction but no doubt have their pros and cons depending on your own experience of them.

0
0
FAIL

The assertion here is too narrow

As companies, in general, don't train, there are many developers who don't know how to properly use ANY of the libraries they touch on a day-to-day bases - open source or not. Most developers can't write good SQL and couldn't construct an outer join without Google or a book for help.

To get the best from any platform, technology or framework you need training - whether that be an expensive, £500-a-day classroom experience or your company giving you a couple of days to read the books and do the online tutorials.

Most companies won't even stoop to that.

2
0
This topic is closed for new posts.