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 hacker.
2. it was discovered by accident, not because of clever due diligence.
Basically, there was a developer who had a flakey connection and one time his commits didn't go through. To detect this in future he had a script that would download the entire tree from the server and compare it against his local copy to make sure that his changes had been committed.
It was discovered because of the discrepancy between his local working copy and the upstream copy. Which was checked not for security reasons, but because sometimes the two were out of sync. That's all. Just dumb luck.
The sysadmins are still quite bitter about it. I know how it feels when your box is hacked and you really take it personally.
The code wasn't added by hacking the CVS, as far as I remember, but rather through a hacked developer with commit rights.
Geez, this crowd. The clearest evidence that it was not an NSA attack is that it was not very good. It modified a CVS mirror. At no time was the source of truth (the bitkeeper repo) in any danger. Anybody that knew how this stuff worked at the time would have known it would be caught immediately. Not very state level expertise, pretty sad if it was the NSA.
> The clearest evidence that it was not an NSA attack is that it was not very good.
I suspect you are being sarcastic, but in case you aren't, you may want to reexamine your assumptions.
The colossal incompetence that is synonymous with government work doesn't magically stop at three-letter agencies. The FBI/CIA communication fuckups before 9/11 are just one famous example.
The idea that the NSA is staffed with "uber hackers" is a Hollywood fantasy. A government job working as a hacker is still a government job. Why would someone with that skillset, who can get a job at FAANG for 10x the salary, submit to the bureaucracy and monitoring BS that comes with working for an intelligence agency? I'm sure there are a select few who find this appealing, but the vast majority are just going the take the money and the free life.
Those two were my wake up calls. The US absolutely is in the hacking business, but they are not in the getting caught business. Everything we have seen so far is incredibly sophisticated and took years to discover. How can you then go out and claim that the NSA isn’t incredibly competent?
See also all of the intelligence the US has provided about the Russian invasion into Ukraine. The US is really good at spy craft.
maybe 10x the salary (probably not) but also a correlated increase in hours instead of a contractually mandated maximum of 40 hours, combined with the legal inability to do work from home, discuss work at home, and a lot of related perks.
Also "perks" like having your life put under the microscope at regular intervals, going to prison if you talk about what you do, etc.
And I strongly doubt that agencies that are known to routinely violate the law, the constitution, and human rights care about "contractually mandated" 40-hour workweeks.
> And I strongly doubt that agencies that are known to routinely violate the law, the constitution, and human rights care about "contractually mandated" 40-hour workweeks.
lol they 100% do.. because they're all contractors bidding for the work.. so if one company bid X man hours for a cost plus contract and won as the lowest bidder and then put in 3x the time, either the winner would sue for being underpaid or, if they were paid, the loserss would sue because of impropriety.
FAANG money is a relatively recent thing. Stock options used to be the only way you might make millions as a developer, at that was always a gamble. The NSA probably has a lot of seasoned developers who started their careers when the pay gap was much smaller.
> I'm sure there are a select few who find this appealing
That’s really all you need dude. And yet both private and public sector intelligence jobs are selective. Supply and demand might help you reconcile your other points.
You slightly underestimate the pool of extremely patriotic or nationalistic smart engineers and scientists around.
If your basic thesis was correct no video games would get made either. Most of them could go get that FAANG money for arguably better work life balance. People have more motivations than you realize. And the idea that all the smartest engineers and scientists exclusively work for FAANG is a contrivance only believed on this dumb site. (The equally idiotic corollary is that all the smartest people work in software).
I also think you are underestimating the lifetime earning potential of top intelligence workers. 9 to 5 government jobs don’t have to be forever.
Finally, the sophistication of state level attacks such as in Iran is clear. The evidence exists, and you are wrong.
And you’re missing the point, it isn’t even that this attack wasn’t sophisticated it was that clearly no one sat down for even a few minutes to discuss how it would be detected. An organization, even a private hacking group, would have discussed this.
Not to mention it being extremely difficult to travel internationally, and not being able to have close personal friendships with many people who live in other countries. Not being able to partake in THC consumption EVER, much less any other recreational substance besides alcohol. The list goes on.
I understand that it pays very well and there's decent work/life balance in terms of hours. But you have to essentially work in a windowless cell with no internet. And for lots of people with the curious hacker mentality, it would be a chore to "keep your nose clean" as they say.
I live in the DC area and the stereotype of the bland, khaki, polo, and white sneakers wearing boring person is true.
This thread is already full of silly archetypes and over generalizations not borne out by the reality. With that in mind: When you say drug using, “curious hacker mentality” all I can think of is Eric Raymond and the implication that this wizard of fetchmail is just too smart to work with the boring likes of von Neumann, Turing and Shannon, Tao, etc.
> Not being able to partake in THC consumption EVER
The all caps tickles me. I don’t think this is a huge sacrifice outside some limited circles. Some of the smartest people are ethical vegetarians.
I replied to their comment because it was related, but where do you get the impression it is not supportive?
I’m responding to the idiots poking holes in that claim.
Wait was the guy you know the hacker or someone who discovered the hack by accident? If the latter, how do you know anything about the hacker's identity or motive?
Sounds like OP interviewed the person who uploaded the code, whose system was previously inflitrated (it can still be the NSA). So why say "If the guy who did it wants to come forward, that is his decision. But he did provide me the full story", it doesn't sound like OP interviewed the "guy who did it"...
I read that the other way. "If the guy who did it wants to come forward, that is his decision. But he [still talking about the guy who did it] did provide me the full story."
That is, the perpetrator gave him the full story, but he won't name names, because it's the perpetrator's choice whether or not to reveal his identity.
he was more specific, but I (a) don't remember the name off the top of my head, and (b) don't think it is beneficial to put them on blast. It isn't their fault they got hacked 20 years ago.
To be clear: you're telling us the full story of the discovery, not the full story of the exploit? You and your source don't know who the attacker was, right?
What is there to say about the hack? Like everything back then it was probably accomplished by exploiting trust relationships. I can ask him, but it is not at interesting 20 years later.
What is there to say about the [discovery]? Like everything back then it was probably accomplished by [a simple source code diff]...it is not at interesting 20 years later.
You get the idea. The story you know might be interesting to you because you happen to know the person involved. And it is sort of interesting? But not really as interesting as the _full_ story would be. In particular because your grammar in your original comment kind of implies you knew the actual attacker.
This all seems fairly obvious to me? Is there anything we're missing about the discovery? It's pretty mundane that one of hundreds of devs working on that source code happened to have a vanilla copy, especially in 2003 with a less reliable and slower internet.
A state actor would have done a much better job. This was detected nearly immediately and anyone that knew how the system was setup (which was public knowledge) would have known this would be caught. The state level hackers are not that dumb.
If there was a serious backdoor attempt, then this was the distractor.
And seriously back in those days especially Linux didn’t need much help with getting root exploits in the tree.
> Like everything back then it was probably accomplished by exploiting trust relationships
That's wrong on many levels. Bold and stupid "hacks" committed by teenagers using SE tend to get a lot of traction, because it is both bold and stupid. This hasn't changed. But "back then" there was much more than that...
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 doesn't belong in a "if". You may get stuff like that in legitimate code with macro expansion, but again, it is not the case here, and from my experience, you get a warning anyways.
You didn't get a warning for that in 2003... or maybe with the pedantic flag. And even if it were the case, it would have been drowned by all the other unfixed warnings...
The only people using linters at that time was because it was forced by regulation (like automotive, aeronautics, ...)
Even now, and I'm pretty sure back then, the relevant warning in GCC is suppressed if the assignment occurs in parentheses, like it did in the diff (clang I believe has the same behaviour). So you would likely need a static analysis tool to flag up the behaviour, and those are quite noisy at the best of times.
Maybe the unit tests should test that the variables you intend to "not touch" do not in fact change. So record UID before and after the function. When I'm writing critical code like this, one gets a tingly feeling when typing in that variable name.
Did unit tests exist in 2003? I don't clearly remember when that idea came along, but comprehensive unit testing certainly was not standard practice 20 years ago... not in any organization I knew about at the time, anyway!
I believe unit tests existed. I had a test training in 2000 and things were pretty systematic already then. Not 100% sure whether the exact term was used then.
Edit: JUnit is from 1997. So the name was definitely in use in 2003. I attended a TDD tutorial before 2004 (don't remember the exact year). CI wasn't a thing yet, so you executed your unit tests manually. /edit
Do unit tests exist in the kernel today? There is some (or some would say a lot) of automatic testing for the kernel, but I don't remember seeing a single unit test.
it still seems kinda weird to me that all it takes to elevate privileges for a user process to "can arbitrarily write system level memory or disk" is just the clearing of all the bits of a single integer in kernel space which can be done by pretty much any execution path in the kernel.
it just seems like there could be a more tamper resistant mechanism around privilege elevations.
Yeah, everything in the kernel is trusted and lives in one address space, just like any normal program. This is part of what would be solved by a microkernel architecture.
Its my understanding that if "OS process" runs with its own address space with privileges (as it needs to talk to hardware), once an attacker has code execution functionality, what stops them from mapping the memory they need then writing to the address to set uid ?
that's part of it. and is the basis of the classic tannenbaum v. torvalds debate, but only part of what i mean.
it would be interesting if there were some kind of write protection on the process-privilege data where some effort is made to verify the provenance of updates before they're allowed to go through or maybe even the whole privilege table is centralized and signed.
We used to use this as a cautionary tale in the CS department security course at the Technion. First, to highlight trust relationships in the "supply chain" (as the notion is now known in contemporary usage). Second, to pose the question of whether open source is inherently more trustworthy.
I guess you could argue that more [evil] people would try to backdoor the linux kernel than there are [malicious] people inside private companies, but the level of trust inside a private company is probably much higher? Seems complex
I think the risk from this type of attack is probably near zero. You can't hack into Github and add a commit to Linux.
Probably most of the deliberate backdoors that are present in Linux have been inserted by well funded state sponsored developers performing useful work. Easy to sneak a vulnerability in that way. (There was a controversial incident a few years ago when some researchers proved as much.)
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.
Really? I think of a backdoor as a deliberate vulnerability, and the exploit as the attack (or attack code) that makes use of any kind of vulnerability.
Let's say the NSA adds a backdoor. If someone else finds it, isn't that an exploit?
Very similarly to yourself, but I would say backdoor and vulnerability are mutually exclusive (kinda? I guess a backdoor is a deliberate vulnerability but I think you know what I mean) yet both can be exploited (the exploit being the client side code, if you will).
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 operator in place of the equals operator in a language, you either have to have a real boolean type, and no implicit conversion of other types to boolean, or make assignments not be an expression, or disallow assignment expressions in boolean contexts.
Making both operators the same symbol is not a good solution IMO, because it makes it harder to distinguish which is which in arbitrary contexts. E.g. in `a = b = c`, presumably the first is an assignment and the second a comparison? Or maybe not? It would just be confusing. Not sure which languages you are referring to that do this.
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.
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 about programming, you often see different notation for assignment and equality. Assignment may be <- or := or something, and equality will just be =, to match the mathematical notation. I see a lot of <- in manuals for processors & architectures. 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.
I would only accept something like that if it meant (a==x)&&(x==y).
> 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.
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, and so I'd prefer the operators to be distinct even if the language do not allow them in the same context)
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?
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)
Modern languages using that syntax tend to prevent that mistake by either outright disallowing assignments in boolean contexts, or by not having implicit conversion of other types to boolean, meaning that the mistake would be limited to the case of comparing a boolean variable to another value, which is quite rare. Some languages further limit the risk by making variables unmodifiable by default, meaning that it would have to be an explicitly modifiable boolean variable.
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.)
Yeah. This doesn't appear to be the same sort of thing (malicious code being integrated into the kernel itself). This is just a backdoor that leverages an exploit.
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.
Not sure what your decision procedure is for "a virus" versus "trustworthy RAT", but there are plenty of open source options out there, in case that helps,
https://medevel.com/18-os-rat-list/
OpenVPN, IPSEC, Wireguard can all be used to tether them to you. If you don't have a static IP then a dynamic DNS service can fix that. Once you have a VPN then use whatever you fancy - RDP for example.
AFAIK, solutions like TeamViewer or AnyDesk may be securely connected from the outside and manage the NAT+firewall of home user... no need to have a RAT (in the "virus/backdoor" meaning)
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.
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 hacker.
2. it was discovered by accident, not because of clever due diligence.
Basically, there was a developer who had a flakey connection and one time his commits didn't go through. To detect this in future he had a script that would download the entire tree from the server and compare it against his local copy to make sure that his changes had been committed.
It was discovered because of the discrepancy between his local working copy and the upstream copy. Which was checked not for security reasons, but because sometimes the two were out of sync. That's all. Just dumb luck.
The sysadmins are still quite bitter about it. I know how it feels when your box is hacked and you really take it personally.
The code wasn't added by hacking the CVS, as far as I remember, but rather through a hacked developer with commit rights.
that's the story as I was told