7 ms·

I think this highlights the general problem of Java EE style architecture. There are many moving pieces and many permutations of how they interact together. It'

I think this highlights the general problem of Java EE style architecture. There are many moving pieces and many permutations of how they interact together. It's practically impossible to understand it in its entirety, and thus impossible to guarantee that it's secure. You're basically plugging holes as you find them, but you're never sure that there aren't more holes you don't know about.

hota_mazi 9y ago
> I think this highlights the general problem of Java EE style architecture. Sounds like you didn't even bother reading the article and jumped at the opportunity to criticize something you don't like. The breach has nothing to do with Java EE and everything to do with Equifax' absurd network configuration.
- yogthos 9y ago
  I'm not jumping to any conclusions. The exploit appears to be a deserialization bug in a the REST plugin for Struts that allowed the attackers to perform arbitrary code execution: >The bug specifically affects a popular plugin called REST, which developers use to handle web requests, like data sent to a server from a form a user has filled out. The vulnerability relates to how Struts parses that kind of data and converts it into information that can be interpreted by the Java programming language. When the vulnerability is successfully exploited, malicious code can be hidden inside of such data, and executed when Struts attempts to convert it. >That means intruders could easily inject malware into web servers, possibly without being detected, and use it to steal or delete sensitive data, or infect computers with ransomware, among other things. https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/ https://qz.com/1073221/the-hackers-who-broke-into-equifax-ex...
  - hota_mazi 9y ago
    Like I said, none of that would have happened if Equifax had used very basic network safety principles. This has nothing to do with Java EE.
    - yogthos 9y ago
      None of that would've happened if Struts didn't have remote code execution bugs in it either. My original point was precisely that there are many attack vectors, and a complex stack makes it nearly impossible to account for all of them.
      - wglb 9y ago
        Name one that is immune. Clue: none are.
        grzm 9y ago
        This kind of statement is the basis of a lot of false equivalence. You're right: there have been exploits found in many different types of systems. Is it easier for bugs to hide in complex systems? Are some systems more complex than others? I think it's pretty unconstriversial to say the answer to both of these are yes. I don't see your parent saying that this could only occur in this stack.
        wglb 9y ago
        Ok, let's try from this angle? Are you familiar with Capability Maturity Model https://www.sei.cmu.edu/reports/93tr024.pdf https://www.sei.cmu.edu/reports/93tr024.pdf? Now we know how to build reliable software to fly airplanes and land men on the moon. The CMM level 5 is a pretty effective component of this. Now if you take the bottom 400 companies of the fortune 500, where do you think their public-facing web sites fare on the CMM scale? As another part of the exercise, what software that does anything remotely interesting is not complex?
        grzm 9y ago
        Thanks for the link. I haven't read it, but from the name and the little I know about NASA software development practices, it's not clear to me at all that these are inconsistent. They're orthogonal, if anything. Are they not? Is there something in CMM that says that complex systems are not more difficult to understand (and therefore more likely to hide/contain bugs)? Where a particular set of companies falls on such a scale is also independent of this, isn't it? I feel like I'm missing something (which admittedly may be because I haven't read the linked PDF), so if you'd be willing to take the time to expound, I'd appreciate it.
astral303 9y ago
The real problem is that the Java EE style architecture introduces so many bullshit layers that you lose sight of real layers that you need to worry about.
- solomatov 9y ago
  Please, read the description of the bug. The bug isn't caused by layers of composition. In many sense, the bug is very similar to SQL injection.
cjhanks 9y ago
Not sure why you were down-voted. This seems true enough to me.
- abiox 9y ago
  i can't downvote; but to me it seems like they didn't provide any evidence, data or rationale. it was mostly assertions.
- pstuart 9y ago
  Currently porting such software to Go. Java has become the assembly language of the Framework. Yuck.
w4tson 9y ago
I call bullshit. The EE eco system while not perfect is basically a best in class for framework for everything we've learned about building business apps over the last 20 years.
- bschwindHN 9y ago
  This doesn't refute the point you're replying to, you're essentially saying "Nuh uh it's the best" Too many knobs and dials can be a big problem, and verifying you have everything set up optimally for production is tough with all that configuration present.
  - abiox 9y ago
    > Too many knobs and dials can be a big problem, and verifying you have everything set up optimally for production is tough with all that configuration present. this seems like a tautology. too many knobs is too many.
    - thaumasiotes 9y ago
      "Too many" of something is bad by definition, but it's not a "big problem" by definition.
    - seandougall 9y ago
      I don't think it's a stretch to read the comment as "Java EE has too many knobs and dials", which is very much not a tautology. (Whether it's true or not is another matter, and not a point I'm qualified to argue)
  - w4tson 9y ago
    "general problem of Java EE style architecture." What style is that? The style of composing persistence technology, Authentication and Authorization, dependency injection, messaging, web communication etc to make a business application? If you know of a magical tech that doesn't aim to solve these problems in a standardized modular way so that the developer isn't socket programming from the ground up then please chip in. "There are many moving pieces and many permutations of how they interact together." Agreed. The problem space isn't todo apps or "Hotdog/No hotdog". "It's practically impossible to understand it in its entirety, and thus impossible to guarantee that it's secure." I don't understand the finer points of the myriad of TLS cypher suites etc, probably means I can't guarantee that they're secure. But what other option do I have? roll my own? Nope I'll take sensible defaults and twiddle the knobs where the client's requirements demand something different. "You're basically plugging holes as you find them, but you're never sure that there aren't more holes you don't know about." - this is FUD.
islanderfun 9y ago
This seems legit. I haven't used Java (SE) in at least 10 years. I'd like to read more on this if anyone has any intel.
tetha 9y ago
Hm, I feel like this should be true for most web stacks which automagically do everything for you. At least PHP and Ruby-frameworks have had trouble with convenient just-working auto-serializers and auto-deserializers.
- yogthos 9y ago
  I agree absolutely, any framework that does things magically is difficult to reason about. Things that are difficult to reason about are inherently insecure in my opinion.
Lightbody 9y ago
I don't think you're being very fair or particularly accurate. There is a massive difference between an over-engineered WebSphere-based deployment using EntityBean EJBs (1.0 no less!) and a tight deployment of Jetty + Struts 2.0 (or more recent frameworks). Anyone who has done real Java development knows this difference. The embedded Jetty + web framework movement was the start of today's modern frameworks, such as Play and various microservices toolkits. The Servlet spec was probably the only good thing to come from JavaEE and Struts falls into that camp, even if it's fairly dated these days. Painting it with a broad "Java EE" brush, with all the bloat that went with it, isn't right.
wglb 9y ago
Pick any complex web application, whether it be written in python, .net, C, C++. The complexity of anything interesting is beyond the scope of one mind to comprehend.

hota_mazi 9y ago

> I think this highlights the general problem of Java EE style architecture. Sounds like you didn't even bother reading the article and jumped at the opportunity to criticize something you don't like. The breach has nothing to do with Java EE and everything to do with Equifax' absurd network configuration.

yogthos 9y ago
I'm not jumping to any conclusions. The exploit appears to be a deserialization bug in a the REST plugin for Struts that allowed the attackers to perform arbitrary code execution: >The bug specifically affects a popular plugin called REST, which developers use to handle web requests, like data sent to a server from a form a user has filled out. The vulnerability relates to how Struts parses that kind of data and converts it into information that can be interpreted by the Java programming language. When the vulnerability is successfully exploited, malicious code can be hidden inside of such data, and executed when Struts attempts to convert it. >That means intruders could easily inject malware into web servers, possibly without being detected, and use it to steal or delete sensitive data, or infect computers with ransomware, among other things. https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/ https://qz.com/1073221/the-hackers-who-broke-into-equifax-ex...
- hota_mazi 9y ago
  Like I said, none of that would have happened if Equifax had used very basic network safety principles. This has nothing to do with Java EE.
  - yogthos 9y ago
    None of that would've happened if Struts didn't have remote code execution bugs in it either. My original point was precisely that there are many attack vectors, and a complex stack makes it nearly impossible to account for all of them.
    - wglb 9y ago
      Name one that is immune. Clue: none are.
      - grzm 9y ago
        This kind of statement is the basis of a lot of false equivalence. You're right: there have been exploits found in many different types of systems. Is it easier for bugs to hide in complex systems? Are some systems more complex than others? I think it's pretty unconstriversial to say the answer to both of these are yes. I don't see your parent saying that this could only occur in this stack.
        wglb 9y ago
        Ok, let's try from this angle? Are you familiar with Capability Maturity Model https://www.sei.cmu.edu/reports/93tr024.pdf https://www.sei.cmu.edu/reports/93tr024.pdf? Now we know how to build reliable software to fly airplanes and land men on the moon. The CMM level 5 is a pretty effective component of this. Now if you take the bottom 400 companies of the fortune 500, where do you think their public-facing web sites fare on the CMM scale? As another part of the exercise, what software that does anything remotely interesting is not complex?
        grzm 9y ago
        Thanks for the link. I haven't read it, but from the name and the little I know about NASA software development practices, it's not clear to me at all that these are inconsistent. They're orthogonal, if anything. Are they not? Is there something in CMM that says that complex systems are not more difficult to understand (and therefore more likely to hide/contain bugs)? Where a particular set of companies falls on such a scale is also independent of this, isn't it? I feel like I'm missing something (which admittedly may be because I haven't read the linked PDF), so if you'd be willing to take the time to expound, I'd appreciate it.

astral303 9y ago

The real problem is that the Java EE style architecture introduces so many bullshit layers that you lose sight of real layers that you need to worry about.

solomatov 9y ago
Please, read the description of the bug. The bug isn't caused by layers of composition. In many sense, the bug is very similar to SQL injection.

cjhanks 9y ago

Not sure why you were down-voted. This seems true enough to me.

abiox 9y ago
i can't downvote; but to me it seems like they didn't provide any evidence, data or rationale. it was mostly assertions.
pstuart 9y ago
Currently porting such software to Go. Java has become the assembly language of the Framework. Yuck.

w4tson 9y ago

I call bullshit. The EE eco system while not perfect is basically a best in class for framework for everything we've learned about building business apps over the last 20 years.

bschwindHN 9y ago
This doesn't refute the point you're replying to, you're essentially saying "Nuh uh it's the best" Too many knobs and dials can be a big problem, and verifying you have everything set up optimally for production is tough with all that configuration present.
- abiox 9y ago
  > Too many knobs and dials can be a big problem, and verifying you have everything set up optimally for production is tough with all that configuration present. this seems like a tautology. too many knobs is too many.
  - thaumasiotes 9y ago
    "Too many" of something is bad by definition, but it's not a "big problem" by definition.
  - seandougall 9y ago
    I don't think it's a stretch to read the comment as "Java EE has too many knobs and dials", which is very much not a tautology. (Whether it's true or not is another matter, and not a point I'm qualified to argue)
- w4tson 9y ago
  "general problem of Java EE style architecture." What style is that? The style of composing persistence technology, Authentication and Authorization, dependency injection, messaging, web communication etc to make a business application? If you know of a magical tech that doesn't aim to solve these problems in a standardized modular way so that the developer isn't socket programming from the ground up then please chip in. "There are many moving pieces and many permutations of how they interact together." Agreed. The problem space isn't todo apps or "Hotdog/No hotdog". "It's practically impossible to understand it in its entirety, and thus impossible to guarantee that it's secure." I don't understand the finer points of the myriad of TLS cypher suites etc, probably means I can't guarantee that they're secure. But what other option do I have? roll my own? Nope I'll take sensible defaults and twiddle the knobs where the client's requirements demand something different. "You're basically plugging holes as you find them, but you're never sure that there aren't more holes you don't know about." - this is FUD.

islanderfun 9y ago

This seems legit. I haven't used Java (SE) in at least 10 years. I'd like to read more on this if anyone has any intel.

tetha 9y ago

Hm, I feel like this should be true for most web stacks which automagically do everything for you. At least PHP and Ruby-frameworks have had trouble with convenient just-working auto-serializers and auto-deserializers.

yogthos 9y ago
I agree absolutely, any framework that does things magically is difficult to reason about. Things that are difficult to reason about are inherently insecure in my opinion.

Lightbody 9y ago

I don't think you're being very fair or particularly accurate. There is a massive difference between an over-engineered WebSphere-based deployment using EntityBean EJBs (1.0 no less!) and a tight deployment of Jetty + Struts 2.0 (or more recent frameworks). Anyone who has done real Java development knows this difference. The embedded Jetty + web framework movement was the start of today's modern frameworks, such as Play and various microservices toolkits. The Servlet spec was probably the only good thing to come from JavaEE and Struts falls into that camp, even if it's fairly dated these days. Painting it with a broad "Java EE" brush, with all the bloat that went with it, isn't right.

wglb 9y ago

Pick any complex web application, whether it be written in python, .net, C, C++. The complexity of anything interesting is beyond the scope of one mind to comprehend.