51–60 of 105 posts
it just seems like there could be a more tamper resistant mechanism around privilege elevations.
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…
Wasn't this done by Ac1dB1tch3z? See http://phrack.org/issues/64/15.html for the CVS exploit from the same time.
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…
Today, certainly. My compiler even catches errors in the format strings to printf[1].
But back then? I doubt it, even with all the warnings turned up.
[1] Removing yet another common source of bugs.
I'm pretty sure there are tons on unreleased and unpublished backdoor exploits for linux and windows likewise. The problem is you can't fix them yourself if the signature keeps unknown to anyone.
“Backdoor” means something deliberately and specifically added to enable the vulnerability. I.e., something can't really be both a backdoor and an exploit.
Let's say the NSA adds a backdoor. If someone else finds it, isn't that an exploit?
Previous discussions - [1] [2] [1] https://news.ycombinator.com/item?id=24106213 [2] https://news.ycombinator.com/item?id=18173173
The Linux Backdoor Attempt of 2003 (2013) - https://news.ycombinator.com/item?id=24106213 - Aug 2020 (141 comments)
The Linux Backdoor Attempt of 2003 - https://news.ycombinator.com/item?id=18173173 - Oct 2018 (28 comments)
The Linux Backdoor Attempt of 2003 - https://news.ycombinator.com/item?id=6520678 - Oct 2013 (63 comments)
> 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?
I don’t think strong/weak typing is the culprit here. I think partly that being explicit is nice. Assignment and equality are two very different things, so it makes sense for there to be different syntax. You can easily prevent the code in the article from working—just disallow assignment inside of expressions. This is probably a good idea, and a lot of newer languages make that choice. Even when you read papers abou…
> a = x = y;
> If that meant “set ‘a’ to true if ‘x’ is equal to ‘y’, and false otherwise.” I would, honestly, be a little pissed off.
Would you find it more acceptable as `a = (x = y)`? To me, that is reasonably clear.
Earlier quoted context omitted.
I don’t think strong/weak typing is the culprit here. I think partly that being explicit is nice. Assignment and equality are two very different things, so it makes sense for there to be different syntax. You can easily prevent the code in the article from working—just disallow assignment inside of expressions. This is probably a good idea, and a lot of newer languages make that choice. Even when you read papers abou…
> I would hate to see something like this in my code base: > a = x = y; > If that meant “set ‘a’ to true if ‘x’ is equal to ‘y’, and false otherwise.” I would, honestly, be a little pissed off. Would you find it more acceptable as `a = (x = y)`? To me, that is reasonably clear.
No, I don’t consider that acceptable. It is not enough that it is clear to some people who know what they are looking at. The language should be more clear to more people.
> 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?
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,…
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?
Assignment is one of the most frequent operations in typical programming languages, so it makes sense for it to be a single-character symbol, and ‘=’ is about the only fitting ASCII symbol for that. (With non-ASCII, there would be ‘≔’ or ‘←’ (the latter being used by APL), but those are non-obvious to type.)