Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux backdoor attempt of 2003 (2013)

freedom-to-tinker.com

Post reply on HN
Print view View original

61–70 of 105 posts

Re: The Linux backdoor attempt of 2003 (2013)

#61

Post by akira2501 »

layer8 wrote: post #49
charonn0 wrote: post #34

> it said "= 0" rather than "== 0" Why do so many programming languages have different equals/assigns operators? There are languages that combine them and apparently don't have any problems. Is it something to do with being strongly vs. weakly typed?

The C designers wanted to be able to write stuff like `while ((ch = getchar()) != EOF) { ... }`, so assignment needed to be an expression. Secondly, C had no boolean type, and instead integers were used for boolean values (zero is false, nonzero is true). The combination of these two facts entails that an integer assignment is also a valid boolean expression. To prevent accidental or malicious use of the assignment o…

> or make assignments not be an expression,

Or just reverse the expression:

    0 == curent->uid
So that the bug case is an error:

    0 = current->uid

Re: The Linux backdoor attempt of 2003 (2013)

#62

Post by diath »

GuB-42 wrote: post #29
ijustlovemath wrote: post #10

Another bit of cleverness not mentioned in the article is that assignment expressions always evaluate to the rvalue. So the expression `current->uid = 0` has the effect of making sure that entire conditional never actually runs (or at least, the return never runs), which means the overall behavior of wait4 doesn't change in an observable way. Very clever if you're trying to pass all of the existing tests

But that should be something the compiler could catch. The expression is always false and the condition would never be executed. You usually get a warning for that. And if the compiler doesn't, linters do. This is a common mistake, and I believe most linters have rules for that. And I don't think there is any situation where there is a good reason for code like this to exist. Either the expression is wrong, or it doe…

The compiler does not, but tools like clang-tidy do, (bugprone-assignment-in-if-condition in clang-tidy) but that didn't exist back then.

Re: The Linux backdoor attempt of 2003 (2013)

#63

Post by hulitu »

grugq wrote: post #3

I have the full story on that incident. It is actually really funny. If the guy who did it wants to come forward, that is his decision. [edit: I won't name names.] He did provided me the full story. He told me with the understanding that the story would go public, so I will dig it up and post it. I also interviewed the sysadmins who were running the box at the time. 1. it was not an NSA operation, it was done by a ha…

> 1. it was not an NSA operation, it was done by a hacker.

Just like the NPR is not financed by the US government, but by NGOs.

Re: The Linux backdoor attempt of 2003 (2013)

#64

Post by krylon »

layer8 wrote: post #49
charonn0 wrote: post #34

> it said "= 0" rather than "== 0" Why do so many programming languages have different equals/assigns operators? There are languages that combine them and apparently don't have any problems. Is it something to do with being strongly vs. weakly typed?

The C designers wanted to be able to write stuff like `while ((ch = getchar()) != EOF) { ... }`, so assignment needed to be an expression. Secondly, C had no boolean type, and instead integers were used for boolean values (zero is false, nonzero is true). The combination of these two facts entails that an integer assignment is also a valid boolean expression. To prevent accidental or malicious use of the assignment o…

A common idiom to defang this was the "Yoda assignment":

  if (0 == do_something(foo)) { ... }
If one accidentally omits one equals-sign, it makes the compiler barf instead of becoming a silent-but-deadly kind of bug (whether intentional or not).

In Go, an assignment is not an expression, so the whole thing becomes illegal. I found this approach a bit offensive at first, but I got used to it rather quickly.

Re: The Linux backdoor attempt of 2003 (2013)

#65

Post by [deleted] »

grugq wrote: post #3

I have the full story on that incident. It is actually really funny. If the guy who did it wants to come forward, that is his decision. [edit: I won't name names.] He did provided me the full story. He told me with the understanding that the story would go public, so I will dig it up and post it. I also interviewed the sysadmins who were running the box at the time. 1. it was not an NSA operation, it was done by a ha…

[deleted]

Re: The Linux backdoor attempt of 2003 (2013)

#66

Post by layer8 »

akira2501 wrote: post #61
layer8 wrote: post #49

Earlier quoted context omitted.

The C designers wanted to be able to write stuff like `while ((ch = getchar()) != EOF) { ... }`, so assignment needed to be an expression. Secondly, C had no boolean type, and instead integers were used for boolean values (zero is false, nonzero is true). The combination of these two facts entails that an integer assignment is also a valid boolean expression. To prevent accidental or malicious use of the assignment o…

> or make assignments not be an expression, Or just reverse the expression: 0 == curent->uid So that the bug case is an error: 0 = current->uid

Yes, that is well known, but it doesn’t prevent the issue in TFA.

Re: The Linux backdoor attempt of 2003 (2013)

#67

Post by vidarh »

charonn0 wrote: post #59
vidarh wrote: post #48

Earlier quoted context omitted.

Some to make them more distinct. Some because they treat assignment as an expression, and so either can occur in the same context. In the former you could combine them. In the latter you can't (you need to be able to tell if "if (a = b) ..." contains a comparison or assignment). (EDIT: I agree with the sibling reply from klodolph there - there are many cases where reusing the same operator would get really confusing,…

It's been my impression over the years that = vs. == is one of the most common mistakes made in languages that use them. In which case, can it really be said to be less confusing?

There are two orthogonal issues here:

1) Do you allow assignment as an expression?

2) Do you use the same operator?

If you answer "yes" to #1, you must answer no to #2, but if you answer no to #1 you can choose whether or not you use the same operator. Consider these examples (assuming that if they're different, we use =/==, but of course any other set of operators could be substituted):

    # A) if 'yes' to 1 this would be a "double assignment", setting both a and b to c.
    a = b = c

    # B) if 'no' to 1, and 'yes' to 2, this would be an assignment of the comparison of b and c to a:
    a = b = c

    # C) if 'no' to 1 and 'no' to 2, this would be an assignment of the comparison of b and c to a:
    a = b == c

    # D) if 'no' to 1 and 'no' to 2, this would most likely be a syntax error:
    a = b = c
With respect to confusion, I'd argue that B) creates a lot of potential for confusion. You'd want "a = b = c" to either be "double assignment" (A) or a syntax error (D). If your language does not allow assignments as expressions, I'd go for C/D exactly for the reason you give, as the main reason not to allow assignments as expressions tends to be exactly to avoid the mistake you mention (it's trivial to support in a compiler/interpreter, so it's a question of whether you believe it's more helpful or more damaging)

Re: The Linux backdoor attempt of 2003 (2013)

#68

Post by avidiax »

aftbit wrote: post #12

While I'm here, does anyone know of a good trustworthy RAT for Windows machines that I can control from my Linux box? I have some relatives for whom I provide technical support. I'd love to just put an EXE on their desktop that would launch a VNC session and connect back to me (since they have the typical NAT + firewall of home users), but I don't want to install a virus on their machines.

Put Tailscale on their machines and use a normal remote desktop application (probably the built-in RDP). Or put a RaspberryPi with Tailscale on their network.

Just make sure you set the key for those clients to not expire.

Re: The Linux backdoor attempt of 2003 (2013)

#69

Post by akira2501 »

layer8 wrote: post #66
akira2501 wrote: post #61

Earlier quoted context omitted.

> or make assignments not be an expression, Or just reverse the expression: 0 == curent->uid So that the bug case is an error: 0 = current->uid

Yes, that is well known, but it doesn’t prevent the issue in TFA.

How does it not? Applied literally to the article, it would have turned this backdoor into a compile time error.

Re: The Linux backdoor attempt of 2003 (2013)

#70

Post by unethical_ban »

hulitu wrote: post #63
grugq wrote: post #3

I have the full story on that incident. It is actually really funny. If the guy who did it wants to come forward, that is his decision. [edit: I won't name names.] He did provided me the full story. He told me with the understanding that the story would go public, so I will dig it up and post it. I also interviewed the sysadmins who were running the box at the time. 1. it was not an NSA operation, it was done by a ha…

> 1. it was not an NSA operation, it was done by a hacker. Just like the NPR is not financed by the US government, but by NGOs.

NPR is not (majority) financed by the US government.

https://www.npr.org/about-npr/178660742/public-radio-finance...

edit - removed some snark

Post reply on HN