3 ms·

> Almost every "rule" SEI CERT has for Java either applies directly to C, or is mooted by C's fundamental insecurity. Did you read the article? That is precis

by wsxcde 11y ago

> Almost every "rule" SEI CERT has for Java either applies directly to C, or is mooted by C's fundamental insecurity. Did you read the article? That is precisely what it says: > The preceding analysis demonstrates that all of the high-severity Java rules also apply to C code, except for those in Java's biggest category, which is internal privilege escalation (IPE). C has no possibility of IPE because C lacks an internal privilege model. We also note that C's biggest security category is memory corruption, which does not affect Java code. The article ends with: > If you are writing unprivileged code, therefore, you have many fewer rules to worry about in Java than you do in C. Consequently, this table strongly hints that Java is more secure than C. In fact, as we showed earlier, all nine of the remaining high-severity Java rules also apply to C, which provides more rigorous support for our hypothesis.

tptacek 11y ago
I did read the article, carefully. Notice the "if you are writing unprivileged code" predicate on that paragraph. First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets. But more importantly, the question doesn't even make sense in context, because you can't ask it if you're comparing C and Java. IF you are considering C for your project, THEN you are writing unprivileged code one way or the other. Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too, and so now I'm going to rant about how bad the article is.
- monochromatic 11y ago
  Talk about burying the lede.
- jacquesm 11y ago
  > if you are writing unprivileged code I read that as 'if you're writing code not intended to run as 'root'', but as a normal user.
  - tptacek 11y ago
    That's not what it means here.
  - pkinsky 11y ago
    > if you are writing unprivileged code I believe this means running in a sandboxed environment where you are not only not root but also not able to access the file system, spawn processes, etc.
- wsxcde 11y ago
  The article acknowledges that the so-called "IPE rules" only apply to small subset of libraries. (They don't even apply to applets/servlets because the libraries which run these things are supposed to handle the isolation here.) IMO the gist of the article is this: 1. We came in believing that Java is more secure than C. 2. So we thought that Java would require fewer secure coding rules. 3. But it turns out Java has more! What does this mean? Was assumption (1) wrong or is there something else going on? 4. Analysis follows. 5. Our assumption was right, it's just that Java has more stuff than C. IOW, the point of the article was to refute the strawman, "Java has more secure coding rules than C, hence it's harder to write secure Java code than secure C code." I'm not sure what you expected the article to say but just asserting "Java is more secure than C" is useless because you just end up preaching to the choir.
  - tptacek 11y ago
    I didn't read it that way at all, but agree that an article that effectively refuted that straw man would be a good thing.
  - cows_i_have 11y ago
    That's a pretty good summary. It can be pretty tough to analyse permissions across a big Java application though, which is harder than analysing a small C programme that does some kind of math simulation or something. So I can see the real world application of this paradigm.
- ScottBurson 11y ago
  > Notice the "if you are writing unprivileged code" predicate on that paragraph. > First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets.* I think the intent is clarified by an earlier paragraph: The IPE rules are designed for code to handle untrusted code, including in applet containers and servlet containers, such as JBoss and Tomcat, and any libraries these containers may depend on, such as the Java core libraries. If you are writing Java core library code, or code that is used in a servlet framework, the IPE rules apply to you. If you are writing only desktop applications, applets, or servlets themselves, however, you can ignore the IPE rules. I think the author, trying to be fair and balanced, is conceding that there is a small amount of code, written by a few people, that is subject to the IPE rules, which complicate the writing of secure code. Does that mean that for the purpose of writing such code, Java is "as insecure" as C? He doesn't say that, or even suggest it; he's merely pointing out that it mostly doesn't matter, since very few of us write such code. > Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too The article is written very coyly and the author doesn't show his hand until the end. I started out tempted to have the same reaction you did, but then I got to this sentence in the third paragraph: We acknowledge that the number of rules for any domain is an interesting but not persuasive metric regarding the domain's security. Then I thought, okay, maybe this isn't as stupid as it looks, let's see where it's going.
Eridrus 11y ago
The incredibly obvious conclusion and ridiculous method makes this an article that shouldn't have been written or posted to HN in the first place.
- nickpsecurity 11y ago
  Exactly. Especially the method. I don't know if I should be annoyed people are paid to write stuff like this or be looking to get a job there for the easy money.

by wsxcde 11y ago

tptacek 11y ago

I did read the article, carefully. Notice the "if you are writing unprivileged code" predicate on that paragraph. First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets. But more importantly, the question doesn't even make sense in context, because you can't ask it if you're comparing C and Java. IF you are considering C for your project, THEN you are writing unprivileged code one way or the other. Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too, and so now I'm going to rant about how bad the article is.

monochromatic 11y ago
Talk about burying the lede.
jacquesm 11y ago
> if you are writing unprivileged code I read that as 'if you're writing code not intended to run as 'root'', but as a normal user.
- tptacek 11y ago
  That's not what it means here.
- pkinsky 11y ago
  > if you are writing unprivileged code I believe this means running in a sandboxed environment where you are not only not root but also not able to access the file system, spawn processes, etc.
wsxcde 11y ago
The article acknowledges that the so-called "IPE rules" only apply to small subset of libraries. (They don't even apply to applets/servlets because the libraries which run these things are supposed to handle the isolation here.) IMO the gist of the article is this: 1. We came in believing that Java is more secure than C. 2. So we thought that Java would require fewer secure coding rules. 3. But it turns out Java has more! What does this mean? Was assumption (1) wrong or is there something else going on? 4. Analysis follows. 5. Our assumption was right, it's just that Java has more stuff than C. IOW, the point of the article was to refute the strawman, "Java has more secure coding rules than C, hence it's harder to write secure Java code than secure C code." I'm not sure what you expected the article to say but just asserting "Java is more secure than C" is useless because you just end up preaching to the choir.
- tptacek 11y ago
  I didn't read it that way at all, but agree that an article that effectively refuted that straw man would be a good thing.
- cows_i_have 11y ago
  That's a pretty good summary. It can be pretty tough to analyse permissions across a big Java application though, which is harder than analysing a small C programme that does some kind of math simulation or something. So I can see the real world application of this paradigm.
ScottBurson 11y ago
> Notice the "if you are writing unprivileged code" predicate on that paragraph. > First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets.* I think the intent is clarified by an earlier paragraph: The IPE rules are designed for code to handle untrusted code, including in applet containers and servlet containers, such as JBoss and Tomcat, and any libraries these containers may depend on, such as the Java core libraries. If you are writing Java core library code, or code that is used in a servlet framework, the IPE rules apply to you. If you are writing only desktop applications, applets, or servlets themselves, however, you can ignore the IPE rules. I think the author, trying to be fair and balanced, is conceding that there is a small amount of code, written by a few people, that is subject to the IPE rules, which complicate the writing of secure code. Does that mean that for the purpose of writing such code, Java is "as insecure" as C? He doesn't say that, or even suggest it; he's merely pointing out that it mostly doesn't matter, since very few of us write such code. > Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too The article is written very coyly and the author doesn't show his hand until the end. I started out tempted to have the same reaction you did, but then I got to this sentence in the third paragraph: We acknowledge that the number of rules for any domain is an interesting but not persuasive metric regarding the domain's security. Then I thought, okay, maybe this isn't as stupid as it looks, let's see where it's going.

Eridrus 11y ago

The incredibly obvious conclusion and ridiculous method makes this an article that shouldn't have been written or posted to HN in the first place.

nickpsecurity 11y ago
Exactly. Especially the method. I don't know if I should be annoyed people are paid to write stuff like this or be looking to get a job there for the easy money.