Julian Assange: Debian Is Owned By The NSA
In his Q&A to his keynote address at the World Hosting Days Global 2014 conference in April, the world’s largest hosting and cloud event, Julian Assange discussed encryption technology in the context of hosting systems. He discussed the cypherpunk credo of how encryption can level the playing field between powerful governments and people, and about 20 minutes into his address, he discussed how UNIX-like systems like Debian (which he mentioned by name) are engineered by nation-states with backdoors which are easily introduced as ‘bugs’, and how the Linux system depends on thousands of packages and libraries that may be compromised.
I recommend watching his 36 minute Q&A in its entirety, keeping in mind my recent warnings about how GNU/Linux is almost entirely engineered by the government/military-affiliated Red Hat corporation.
The Voice of Russia website has an article on Assange’s address with a few quotes:
“To a degree this is a matter of national sovereignty. The news is all flush with talk about how Russia has annexed the Crimea, but the reality is, the Five Eyes intelligence alliance, principally the United States, have annexed the whole world as a result of annexing the computer systems and communications technology that is used to run the modern world,” stated Julian Assange in his keynote address…
Don’t just read the short article, listen to the address yourself, because Assange goes into many areas, and the work being done in these fields.
Assange mentions how Debian famously botched the SSH random number generator for years (which was clearly sabotaged). Speaking of botched security affecting Red Hat, Debian, Ubuntu, Gentoo, SuSE, *BSD, and more, the nightmarish OpenSSL recently botched SSL again (very serious – updated comments on how a defense contractor in Finland outed the NSA here?) It’s very hard to believe this wasn’t deliberate, as botching the memory space of private keys is about as completely incompetent as you can get, as this area is ultra-critical to the whole system. As a result, many private keys, including of providers, were potentially compromised, and much private info of service users. Be sure to update your systems as this bug is now public knowledge. (For more on how OpenSSL is a nightmare, and why this bug is one among many that will never be found, listen to FreeBSD developer Poul-Heening Kamp’s excellent talk at the FOSDEM BSD conference.)
From the start, my revelations on this blog about Red Hat’s deep control of Linux, along with their large corporate/government connections, hasn’t been just about spying, but about losing the distributed engineering quality of Linux, with Red Hat centralizing control. Yet as an ex-cypherpunk and crypto software developer, as soon as I started using Linux years ago, I noted that all the major distributions used watered-down encryption (to use stronger encryption in many areas, such as AES-loop, you needed to compile your own kernel and go to great lengths to manually bypass barriers they put in place to the use of genuinely strong encryption). This told me then that those who controlled distributions were deeply in the pockets of intelligence networks. So it comes as no surprise to me that they jumped on board systemd when told to, despite the mock choice publicized to users – there was never any option.
A computer, and especially hosting services (which often run Linux), are powerful communication and broadcasting systems into today’s world. If you control and have unfettered access to such systems, you basically control the world. As Assange notes in the talk, encryption is only as strong as its endpoints. eg if you’re running a very secure protocol on a system with a compromised OS, you’re owned.
As Assange observed:
“The sharing of information, the communication of free peoples, across history and across geography, is something that creates, maintains, and disciplines laws [governments].”
UPDATE: Wikileaks is officially denying that Julian Assange literally said “Debian Is Owned By The NSA”. For people who are choking on the mere summary title of this article, please see definition of Owned/Pwn (and get some hip!)
Related:
- Ts’o and Linus And The Impotent Rage Against systemd
- Biography of a Cypherpunk, and How Cryptography Affects Your Life
(second half details Red Hat’s involvement in Linux)
125 Comments »
Leave a Reply
About
This blog is where you can check on the latest updates to my Linux software, news and tips, and leave your comments and questions.
TERMS OF USE
Do you have any link for the Debian SSL random number disaster being deliberate sabotage? At the time, I thought that it was pretty much gross incompetence, and any sabotage would be more like the Poettering/Sievers model, where you put somebody incompetent and arrogant into a position to introduce severe flaws which they are bound to do sooner or later. Now, from the outside, it may have looked like a not-really well disguised deliberate flaw, but what I have seen in terms of crypto-implementation in the real world and the people doing it (and I know some personally), mistakes this severe happen all the time and the people responsible are at least in some case that I can personally judge really this grossly incompetent or just do not have the background to understand what they are doing. Crypto is hard, and often it gets assigned to a normal developer that has no clue that it is fundamentally different from other code.
As to the new SSL issue, I am really undecided. OpenSSL really and urgently needs to clean up their project structure, documentation and code. But what I see is compatible with what I see on a lot of other places, and I would be surprised if all of it or even most of it was sabotage. My impression is rather that the NSA people looked at what crypto is done in practice by people with huge egos and small skills and decided that they actually do not need sabotage most FOSS use of crypto as it sucks badly as implemented.
Of course, they may have done indirect things, like hiring away or neutralizing people that could do better and subtly maneuvering incompetent people into positions of power and influence.
I would also like to point out that in the Debian SSL Disaster, the crypto was fine, but that the CPRNG seeding was flawed, which is not strictly a crypto issue and a mistake made both many, many times before and too subtle for most software people to understand unless it is explained to them. (Yes, I know, this is pathetic, but I had to personally explain the importance of good seeding for CPRNGs to quite a few people implementing security critical software. IT people just do not understand randomness at all. They even still botch non-cryptographic use.) The current SSL flaw is also not a crypto flaw, but a flawed use or rather a flawed protocol implementation as far as I can see. Now, I am not saying that makes these things less severe, but it gives us that we can probably trust the mathematics, but not the things most people are doing with it. Andm as always, it tells us that KISS is the only true way and complexity is the enemy.
I don’t have links handy on Debian’s RNG bug. The reason it’s known as sabotage is that someone emailed the developer (or reported a bug) which basically said ‘remove these specific lines of code because they do nothing’. The developer obliged and created a huge security flaw in Debian that lasted for years before it was reported. Whoever this saboteur was, he knew just what to request to be removed. And the developer went along with it, no questions asked. He can claim he didn’t realize the consequences (marginally plausible deniability), but that seems pretty thin in crypto-related work (and RNGs are VERY MUCH a part of crypto, hence the flaw).
Listen to Poul-Heening Kamp’s talk at the FOSDEM, where he discusses this Debian episode specifically, and how this kind of technique is used with patches, etc. By accepting a patch, the developer can claim deniability (he just didn’t review a patch carefully enough), while the patch came from who-knows-where, and he receives cash/blackmail from who-knows-who. This is one example, but these days most of GNU/Linux is written by Red Hat employees directly, who essentially work for the US military (their largest customer), so the path there is even shorter – just a walk down the hall.
As for people/bots who reject such connections, they won’t be satisfied until they see ‘by NSA’ stamped on a commit, which of course will never be the case (except in selinux, ha). They just work to delay consensus forming on how Linux is completely compromised. Keep it at a slow boil.
As for the algorithms themselves, the math, many like DSA are actually overtly designed by the NSA, so you can be sure they know how to break them, or they wouldn’t offer them. Others are probably expensive but crackable in high-interest cases (we’re talking quantum computers at their disposal). For anything super-critical I think a one-time pad is the only guarantee, and make sure your RNG works!
Personally, I don’t agree with Assange’s stress on privacy and secrets, though that’s important in some contexts. I think the better uses of encryption have to do with anonymity (whistleblowers), openness, transparency, and validation. Let’s see some more work in crypto-secured monetary systems, voting systems, etc. Helping competing governments and corporations to keep secrets from the NSA is questionable as a primary focus. Regardless, its very hard to keep secrets, especially with endpoint vulnerabilities. Yet crypto is powerful when used openly. git is good example.
And of course distributed systems, rather than centralized keys, etc. Assange touched on this a little, although he termed it “encryption providers”. I think having lots of secure, independent systems is the best approach – decentralization. Exactly what Linux is moving away from.
I don’t think so for the Debian SSL Disaster. It would just be too obvious. Running Valgrind is standard whenever you engineer something to be long-running and many people do not really understand what Valgrind tells them and just escalate. (In this case to the package maintainer, who was clueless with regard to how CPRNG seeding works. I find that highly plausible, unfortunately, people are really routinely that incompetent.) Of course, this may have been beautifully crafted, but I doubt it. Too complex, to many ways it could have gone wrong.
Well, DSA is problematic, but that is well-known. There are no indications however that the algorithm itself is breakable, just that design dramatically increases the vulnerability to implementation flaws. Anything ECC is currently highly suspicious, not in the least because the math is complex. For many of the others, I doubt the NSA can actually get in if they are implemented right. And Quantum Computing is bullshit. Sorry, but I happen to know some people in that research community. They basically are lying to the ones providing the funding and telling themselves that this is justified because of secondary results. That type of scam is unfortunately common in academia. For example certain AI folks have been doing this for decades.
Also, CPRNG _seeding_ is not crypto. The CPRNG is, but the seeding is a whole separate (and hard) engineering and physics problem.
I completely agree on decentralization though. Standardized _simple_ protocols, and different implementations of them, because everybody can make their own if they so desire. OpenSSL is already a problem because its use is so widespread.
Now you have me doubting your intentions. As for quantum computing, it is not academic. It is a big part of the NSA’s new $2 BILLION complex in Utah, which insiders report is already online well ahead of public schedule (which would be typical), and Google (another govt front) also has already taken delivery of one. Saying quantum computing is academic (especially to the NSA, which is decades ahead of civilian and conventional military tech) is like saying CPUs are theoretical – they use quantum physics too, and they work (I know, I used to CAD design the substrate layers in CPUs, holes and all). You seem to be spreading FUD (just for readers who may be fooled). And anyone who says RNGs and seeding aren’t a critical aspect of crypto doesn’t know what they’re talking about – more FUD. Even GPG handles seeding itself internally in some modes.
Your views are too inconsistent to be genuine. You are serious into crypto, but don’t know about seeding, and trust DSA. Stick with DES. And you just happen to know someone in quantum computer development personally, and they don’t mind you blabbing that their multi-million dollar grant is bogus. Whatever your intentions are here, FUD-man, give it a rest.
Ain’t paranoia wonderful?
I am not saying quantum computing is academic. I am saying it is a scam. It has all the tell-tales of a scam. The things that Google has taken delivery of is a “magic black box”, that, surprise!, cannot do anything a classical computer cannot do and the classical computer will even be faster doing it. What Google paid for it is peanuts, so they may just be experimenting. As to the NSA, they may have lots of funds and people, but they do not have any “magic” either. Chances are all real computing in Utah is purely classical. And there is the little thing that even a working, scaling QC does not magically break all crypto. For example for block-ciphers, it would half the key-length. But an 128 bit key that would remain of AES-256 is still unbreakable and more so for a QC, because they are inherently slow.
I am also not saying that seeding CPRNGs is uncritical. In fact it is very critical, but it is decidedly not crypto, it is physics, often in the form of electronics. That is one of the reasons it gets screwed up so often. People read a crypo-algorithm book and think they know how to seed a CPRNG. Not so, for that you need to look elsewhere and it requires different skills.
Example: Many people think that the timing of a keystroke gives them a lot of bits if they measure it with microsecond precision. That is completely untrue, as keyboards are scanned synchronously with around 70Hz for the 3 I measured it on. This scanning is crystal driven, i.e. highly precise. As a result, a keystroke gives you maybe 3-4 bit for the first one and as low as a single bit on following ones. But that knowledge is not crypto, it is not taught in crypto and many crypto people do not know that. This knowledge is electronics and you actually have to measure it yourself. (At least I was unable to find any good reference when I looked for it.) Crypto-only people may not even be aware that they need to find this out and just assume, hence breaking the seeding.
I think the problem here is that you only look at the surface of what I seem to be saying. I hope I have made things clearer.
Thanks for persevering and for providing additional details subsequent to your initial comment, Celos. Without those details, one might wonder whether you were just splitting hairs, attempting to be argumentative. I hear ya, loud and clear, on the issue of academians scamming in order to secure funding. Example: the latest drivel, pushed all the way to the public’s eye this week — (is not an untruth, yet _is_ a scam) — yay! US Navy researchers have successfully created fuel from seawater!
I’ve followed this blog for several years. Based on the content of this post (Jules Asswanger is a quotable source of ‘proof’?!?) and the recent drama-laden and misconstrued “systemd journaling triggers a kernel bug” post, I sense that IG has recently lost his center. Dear IG: facts are facts; ‘proof’ is… something else. I sighed when reading this post. The opening sentence begs/screams the need for a supporting hyperlink regarding the word choice ‘proof’. Without such, this post is doomed, relegated to the prospect of likely being perceived as editorial drama. I appreciate your raising awareness by presenting facts. I also appreciate reading the substantive comments here, even those of the hair-splitters. As for ‘proof’, dammit you’re sidetracking. Facts stand for themselves. Hair-splitting is probably inevitable, and reasonable; attacking commenters (“FUD-man”) in an attempt to defend arguments of ‘proof’ is a no-win, for all of us.
> Dear IG: facts are facts; ‘proof’ is… something else
Indeed, and you have provided neither, just emotional trash. As for “proof”, you’re to date the only person in the article and ensuing discussion to use the word. “Celos” has a history on this blog (in fact I suspect he’s you using yet another name and globally erratic IP address). Regardless, this blog is not a politically-correct load of drivel. The way it works here is, I let you say just about anything you want (I have yet to delete or edit a non-spam comment, despite many controversies covered here), and I say whatever I like in addressing what you had to say. We’re all free.
As I said, you’re just as full of it, apparently – if you don’t like my sharing that thought, get lost. Imagine my nerve expressing opinions on my own blog. If you want to interpret Celos as genuine, go for it – no one’s stopping you. Learn to think for yourself instead of whining.
As for quantum computing, quantum entanglement has been demonstrated in labs globally, in physically real and useful ways. The steps from there to engineering are inevitable, and the NSA is decades ahead of civilian tech. As well, there is a ceiling on civilian tech – it isn’t allowed to proceed organically. I can easily thus believe that this technology is in use. And their saying so is in keeping with their releasing such information (including so that conspiracy theories can grow around it, covering their tracks). I’m not a nitwit or a child, I’ve seen technology evolving for decades, and there are patterns, and I expect my education in physics is much more expensive than yours. The idea that the entire field of quantum computer research is merely “bullshit” (notice how I quote someone accurately) is bullshit, and calling them “slow” reveals a complete misunderstanding of how they work.
My suggestion to you is to get on topic and stop trying to derail and confuse the subject at hand ,like your alleged ‘friend’ “Celos”, which is NSA spying in Debian/Linux and the OpenSSL exploit. And lay off the booze for a change, “Celos”.
SSH not SSL
Very saddened by this news. We were just considering a move to Debian (from Ubuntu) for most of our production systems precisely because of the percieved tighter control and attention given to security. A previous commenter in one of your previous blog posts pointed out the possible merit of using a specialized Linux kernel (GNU?). Do the BSD variants warrant increased discussion as an alternative to Red Hat control of the Linux sphere?
I’ve been wondering this myself as I explore ways to move in a direction that doesn’t include systemd. Poul-Heening Kamp’s talk reveals that BSD is prone to many of the same problems. I suspect any modern, reasonably mainstream OS will be. BSD has been more resistant to GNOME3 and systemd adoption, yet some are now including GNOME3. This implies a strong influence from Red Hat in the BSD world as well.
So basically this the problem – that there is no even remotely secure OS, or any OS that is not heavily engineered by government-connected corporations. We are in a place of no good options.
Even aside from security, the larger problem I see is that the whole community development model of Linux is being betrayed. We’re ending up with just another Windows variant, centrally engineered, closed, insecure. Linux is truly becoming hell to develop on. Even the few things that work change rapidly and suck too much time. It’s being engineered to be inaccessible to independent developers, especially at lower levels, yet even in the GUI layer.
I just came across this from a discussion in systemd:
“It’s funny that you propose the BSD’s when the criticism leveraged at systemd is how it threatens the Linux distro and user flexibility when it comes to setting up their system the way they want, when the BSD’s are developed exactly in the way systemd suggests, as a single OS consisting of a fixed set of software from init to kernel.
The flexibility that the systemd detractors claim is lost to them due to systemd does not exist on the BSD’s as they are developed as complete OS’es, there is no user flexibility when it comes to the base system components such as init system etc, the respective BSD’s support their specific OS configuration and that’s it.
In fact what systemd is doing is to bring the Linux ecosystem closer to the way the individual BSD’s work, which is to standarise as a full OS offering rather than (as is the case now) just the Linux kernel.
permalink
parent
[–]whiteychs 1 point 22 days ago
To be fair, that’s because each *BSD is partly an isolated ecosystem apart from the other *BSD’s. For example, FreeBSD and OpenBSD use different kernels and implement some different utilities which can make things non-portable between them.
If the BSDs treated themselves more as Linux distributions of the BSD world then I believe you’d see more flexibility and a greater emphasis on cross-development and compatibility – that’s all conjecture though.
permalink
parent
[–]computesomething 4 points 22 days ago
If the BSDs treated themselves more as Linux distributions of the BSD world then I believe you’d see more flexibility and a greater emphasis on cross-development and compatibility – that’s all conjecture though.
Sure, but they don’t, and that was the point I was making.
Those who complain about systemd from a Linux user perspective almost always claim that systemd becoming a standard component threatens the flexibility that users and distros have when it comes to mixing and matching the low level components of their Linux based system as they see fit, and pointing those people towards the BSD’s makes no sense as the BSD’s are not flexible at all in this respect.”
Could the Heartbleed bug be merely a red herring? Not in the sense that the bug isn’t real (it certainly is), but more of a decoy; could this be used to justify smearing OpenSSL’s name while a big company (hint hint Red Hat) goes public with an in-house solution that promises “better security”? This tactic was used against sysvinit and other init systems to displace them in favor of systemd. It may only take a more sane API and strong documentation to get people to move away from OpenSSL… then wait until the seed’s been planted (the new crypto gets adopted) and take advantage of people.
None of what I’m saying here is rooted in any hard facts, but it seems odd for a critical bug to be brought to light *before* it’s been patched. They let it leak. I wouldn’t be surprised if the information was leaked deliberately, to cause panic and uncertainty. Be on the lookout for “promising” OpenSSL alternatives and be very skeptical.
I am currently working with OpenSSL and it is a mess in all aspects. It may just be that the people reporting the bug wanted to give them a wake-up call. Replacing OpenSSL would also not be easy. On the plus-side, if this is a smear-campaign and somebody comes up with a magically OpenSSL-compatible “alternative”, maybe the OpenSSL folks would finally manage to extract their heads from their backsides and start cleaning up things.
Hey Sporkbox,
I actually couldn’t find much info about who the current developers/maintainers of OpenSSL are, and what their affiliations are. Not to say I did exhaustive research, but I didn’t come across much looking for it. To hear PHK speak of it, and others, it seems it’s hundreds of thousands of lines of code that no one really understands or works with in any depth. This would lead me to believe it was/is developed by some corporate development team. Do we even know that Red Hat developers aren’t directly involved in that too?
I don’t work in crypto anymore so I can’t say what’s really going on in civilian crypto, if anything. The algorithms I see being used I recognize from decades ago, aside from a few new ones the NSA has graciously given us. Much civilian tech, not just in computers, has artificial ceilings (just ask indy microbiologists, if you can find any still alive). My impression is that not much new work is being done in this field, and people can barely keep the implementations of yesterday running. Perhaps OpenSSL is so complex because it’s just a hodge-podge of old implementations crammed together.
I can tell you this – handling private key memory space so poorly (as in Heartbleed’s case) speaks of incompetence so grand that it’s simply worthless. That’s what passes for coding these days, and is just excused as yet another fuck-up. But you simply can’t code crypto with such carelessness and expect anything to be usable in the real world. Toys and children. This is why genuine crypto coders check and re-check their code, check bounds, and test exhaustively – it’s part of the job. The rapid changes in code you see today are part of this trend too, keeping everything in a state of broken and unhardened. Phil would roll in his grave is he wasn’t still alive.
A trend here is to create/catalog exploits, and only close them as you find unfriendlies using them. A lot of this is a low-level war between intelligence agencies of various states. We (the open source community) are really mostly bystanders – very little actual peer-review goes on, certainly not in something as complex as OpenSSL. PHK also spoke about this and how the cert authorities are mostly run by these very same groups, so SSL is compromised globally – way out of date for anything serious.
Red Hat and other corporations seem more than happy to have everyone using OpenSSL – they would put us all in leaky boats. I doubt they have the motivation you describe to replace it, but it’s certainly possible. They seem to be driving Linux more toward the world of Windows, where viruses and exploits flourish in the wild, even beyond the scope of govt agency access. So to that end they may indeed want to replace OpenSSL with something more closed and directly under their control, if it’s not already. I find it very hard to believe it’s really developed in an ‘open’ way (like most everything else in Linux, actual access is probably closed – you can’t change or influence it), but info on who develops it and what their backgrounds and affiliations are would make good reading.
I consider most of these things toys – not to be taken too seriously. They may keep script kiddies out of your business for the time being (what they’re mostly geared toward), but that’s about it.
This series of articles is going a bit viral, so we’ve got some trolls here – buyer beware. ;)
More about the Heartbleed bug – very serious. And Heartbeat’s RFC. Looks mostly developed in germany? Not that this indicates who ‘owned’ it.
Google Security means NSA/US Govt, effectively, but that doesn’t mean they aren’t also the authors or that they didn’t catalog it for their own uses long ago. It may mean it simply went wild so they’re closing it now and graciously reporting it.
Interestingly, OpenSSL’s advisory says only “Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for preparing the fix.”
I guess that partly answers who maintains OpenSSL – Google (govt) – and who ‘found’ the bug. Sounds like they were forced to report it because others found it, but they took credit for it. Win-Win – exploit it for years then look like the hero who finds it. Very typical behavior there. It took multi-billion-dollar, NSA-enhanced Google Security two years to find this serious an exploit in SSL? Yeah, sure it did. And they just happened to find it at the exact same time that others did, just in time to take credit for it.
Their advisory also contains the lie that “A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.” when in reality it can reveal up to 64K per heartbeat, with the total memory retrievable being greater (unlimited except by segment?).
The way I read it, you actually get 64k from the start of a dynamically allocated buffer on the heap onwards on each heartbeat. Depending on memory allocation, this may expose a different area of the heap each time. It seems that this is enough to steal the server certificates and their passwords and more at last on some platforms. It really depends on the details of the memory allocation strategy and its use and these are very tricky. You should not be able to steal anything outside of the heap dynamic memory area and hence code, data-segment and stack should be fine. That does matter very little though if you get the crown jewels of the server this way and some people have demonstrated that they can.
That is _not_ to say some systems may not be vulnerable. It is just to say that even if you do not see the server certificates or anything else critical when you try this attack on your own server that may just be an accident of memory allocation.
What surprises me is that I think a code security scanner like Fortify or a memory debugger like Valgrind should have found this (do not have time to try this myself), as the up to 64k exposed is “uninitialized” (from the compilers PoV). Unfortunately, Valgrind can only find it if the bug is triggered. So somebody would have to use Valgrind and then fuzz the protocol. While that is a sane precaution, I expect it would take a lot of work and require rather significant understanding. It could however be set up with any protocol changes. Another thing that would have prevented this is excessively redundant bounds-checking, i.e. at each time-of-use there is a bounds-check first for everything that has bounds. I do that sometimes, because the slow-down is small. The often-found C-coder attitude of always going for maximum efficiency may be counter-productive here.
As to the advisory wording, to be fair, the meaning could also be read as 64k exposed per case that the missing bounds check has an effect. I see just all-to-common sloppy technical writing here.
Anyways, what is missing in OpenSSL is really good code review for patches and a structural cleanup of OpenSSL to make that review easy. Some secure coding style, like always to do bounds-check at time-of-use, would also help. And of course, OpenSSL would need good documentation. These things are a resource problem though: They need several competent, independent people that have the time, experience and understanding to do this well.
No, the problem is precisely that the memory in question was *not* uninitialised: OpenSSL added its own wrapper around malloc()/free() that keeps memory allocated (past freeing) then reuses it, to specifically defeat counter measures such as Valgrind or those employed in omalloc. Source is Theo de Raadt – http://article.gmane.org/gmane.os.openbsd.misc/211963 – via Felix von Leitner; I looked at the code and confirmed it (and am happy this is not in the older OpenSSL version I use in MirBSD).
How much more obvious can this get that this is deliberate?
– analysis of openssl freelist reuse
Gee, why would they do that? It’s not “infuriating”, it’s called espionage. Yet Linux and BSD continue to use this software, as if they’re completely helpless, which perhaps they are, but shouldn’t be.
So drop all this bullshit work on moving everything to systemd and (re-)write these very broken, fundamental tools.
While it’s not in any way definitive proof http://www.seacat.mobi/blog/heartbleed it looks like it may have been in the wild for few days prior to official reports.
By now we know it’s been exploited in the wild since *at least* November 2013. ☹
Indeed, this bug has been in the wild for YEARS.
This new EFF article reports seacat may be a false positive, but shows some new ones involving spying on Freenode IRC:
“Never permitted near security related”
BS. Who do you trust more, person who made mistake and learnt from it, or person who ‘never’ has made a mistake. Unless person has been in real crisis is not sure if he will collapse or explode when doing so.
I ‘told ya so’ – the bug was introduced in germany (while not particularly meaningful, western intelligence agencies are very active there – one of the ‘hubs’).
Man who introduced serious ‘Heartbleed’ security flaw denies he inserted it deliberately
As I noted in another comment, and others have noted from looking at the code and fix involved, this wasn’t just a slip of the keyboard. This was total exploit, allowing a remote user to access whatever length of memory they chose, with no check performed at all. This is something that any child would know better than to do (not to insult children coders, who are much brighter than this nitwit and his code reviewer).
This shows that ANY code exploits introduced will ALWAYS be explained away as mistakes. You will NEVER get idiots to recognize a smoking gun when they see one. It doesn’t get better than this. That and the fact the problem was obviously deliberately hidden from valgrind-style tools.
Both Robin Seggelmann (who also coauthored the Heartbeat RFC, so not just a flunky there) and his code reviewer Dr Stephen Henson (a security consultant in the UK, another major hub) should NEVER be permitted anywhere near security-related code again, because if they are not owned by some agency, which is highly unlikely, they have proven they are WILDLY incompetent for such work. Unless these developers who introduce these intrusions are take out of circulation one by one, nothing will change. But that will never happen – they’ll likely be promoted. And there are MANY more plants like them.
Who do these people work for, who have they worked for, and why are these two people alone blindly trusted with the security used in so many OSes? Corporations don’t just make these choices randomly, I assure you. Try contributing to Red Hat’s udev or systemd and see how far YOU get. Try asking Google if they’ll let you work in OpenSSL. They were given a ‘license’ for this work by some corporation. My bet is on Google affiliations.
Both Robin Seggelmann (who also coauthored the Heartbeat RFC, so not just a flunky there) and his code reviewer Dr Stephen Henson (a security consultant in the UK, another major hub) should NEVER be permitted anywhere near security-related code again
This is just too funny not to comment on. You realize that Dr. Henson is one of the developers WHO CREATED OPENSSL? He is working on it for decades now. Nobody asked you to use his software, and now he should not be let near his own creation?
[For the record, I thought you were a troll, and wanted to tell you to stop commenting - unless I noticed that it's your blog! jinx! same situation, different actors]
No I don’t know who he is. And yes, I still think he should not be let near OUR OS. This OpenBSD developer agrees.
I think you are a troll, as well as a fool (or worse) for making excuses for such intrusions. Who would support such a thing?
Lots of corporate hacks who are owned participate in and develop OpenSSL, I’m sure. Your loyalties are clear.
You are the epitome of the problem, including your weird sense of what’s funny. I don’t think you belong anywhere near security code either.
Actually, this commenter, who chose to remain anonymous to say that I’m a troll on my own blog because I don’t know this crypto developer’s name, is quite a case study. (Actually Henson does ring a bell somewhere, now that I think of it, but I don’t recall who he is. Security consultants and university employees like these two are prime recruitment material.)
This commenter shows the high-priest attitude of corporate developers used to a hierarchal structure of authority. Anyone who doesn’t know what he knows or who doesn’t behave/speak in the conventional way these developers speak is merely a troll, not worthy to partake in a discussion among the priests. And in his view Henson is simply too big to fail, too big to be held accountable for his actions, in this or any case, because he is part of the crypto establishment. We see these same patterns in politics and banking for example – it’s elitism, simply put. The 1%.
I say this is a prime example of what’s seriously wrong in Linux development, and how it follows a corporate model of elitism and protection of the big-shots. If you take these people like Henson, who in my view is surely on some corporation’s payroll, and is an old insider in intelligence doing what he’s told, out of the loop in Linux, you begin to remove ‘their’ stranglehold on Linux. Yet developers in the ‘inner circles of power’ in Debian and Linux in general, like this commenter, would never allow that to happen on their watch. They obey the bigger dogs, and would never listen to ‘trolls’ who point out the obvious solutions to such incursions.
It’s much like politics – one wants to throw out the lot of them and start from scratch with real people. I know for a fact I don’t want either of these people working on security-related code in MY OS. Get lost, permanently!
Shockingly insightful, we’d see. While I think some of the points here are a bit exaggerated, the systemd doom is indeed coming and turning things to the worse.
Fun fact: MirBSD voluntarily sticks with old OpenSSL. OpenBSD switched two(?) releases ago, and got vulnerabled. One OpenBSD ports committer sits in GNOME, trying to get the others to agree to keep it buildable on the BSDs, too. Makes me wonder if they’ll keep BSD init. (I am considering packaging BSD init for Debian…)
Disclaimer: MirBSD founder, Debian Developer, speaking my own opinion, opposing systemd publicly in general.
Heartbleed was the last nail on the coffin. The “FOSS makes you more secure” illusion is busted.
I will now have a look at what the Russians and Chinese do in software. They are now the less worse choice.
Both the Russians and Chinese seem to be moving in the direction of Linux as well. Ubuntu Kylin in China’s case and Putin seeking to put the Russian government on Linux by 2015 http://www.computerworld.com/s/article/9202638/Putin_to_put_Russian_government_on_Linux_by_2015
The Chinese military however seems to be running some hardened BSD variant http://www.freebsdnews.net/2011/01/04/kylin-chinese-freebsd-based-secure-os/
So lets be pessimistic and assume the whole open source software ecosystem was deliberately infected with thousands of “bugs” like this one, just like Wikipedia is overflown desinfo by lobbyists…
How trustworthy is any open-source software, where basically anyone can contribute, just like anyone can contribute to our great “encyclopedia”?
And people are still telling the urban legend, how FOSS is so more secure, because anyone can look at the code.
I think, we have a much larger problem here at hand…
And it should be noted that this ‘bug’ was not found by peer-review of code, it was found by a defense contractor in Finland. And from what I understand it wasn’t found by them via code review either. It was discovered using a tool that employs fuzzy intrusion detection. Probably they detected private data in the upstream, and tracked it down from there. I’ll bet it took them awhile to find where it was coming from in OpenSSL’s code even so.
I think intrusion detection alarms, and robust firewalls that allow us to control net access on a per-app basis, like the ones in Windows, are sorely needed in Linux, at least as stop-gap measures. Clearly code review is almost non-existent.
Actually, even the idea that anyone can contribute to FOSS is mostly rubbish. Try contributing anything to udev, systemd, etc and see how far you get.
I think open is far better than closed when it comes to security, but that doesn’t mean it’s reviewed. Such exploits exist in closed code too, and there they’re harder to find and prove.
What we really need to do overall is take our components out of the hands of corporations, and develop simple, slow-changing libraries for these things (which should have been done decades ago). But it is politically impossible in GNU/Linux, at least thus far. Even with this, you’ll have plenty of idiots denying it was an intrusion.
I repeat the question I asked a few weeks ago.
So what OS do you guys use / recommend?
There are alternatives to Linux (e.g. Kolibri) – are they worth a 2nd look?
I think the reason you’re not receiving much of an answer on this is the reason I gave above – there are none. We’re in a place of no good options.
I realize people in computers have trouble digesting this answer, as they are used to quick fixes. Yet in this case the problem has no easy fix – if you (we) want a fix, we will have to create one, pretty much from the ground up. And its not just a technological challenge, it’s a social and political one, because no one person can write and maintain an OS by themselves, and any collaborative efforts are socially sabotaged.
This utter failure in Linux security shows just how completely worthless many of its ‘security experts’ are – and having dealt with them in various areas, I have always gathered that.
I second the above. While I prefer Linux-based systems and GNU tools, I’ve been doing considerable reading on the merits of FreeBSD/OpenBSD. I wonder if someone might be able to weigh in here on this. The development on BSD systems seems considerably more incremental as opposed to Linux-based systems.
The solution is not another fictional OS here.
The only real alternative is to stop using computers and disconnecting them from the network, if you have to use them.
The other advantage is that you can have somebody competent review open software for you. That is not cheap, but unlike closed source, you can do it without the vendor knowing or cooperating by giving you the sources (which then may or may not be what the executable was built from.)
I completely agree on the “simple, slow-changing libraries”. This also requires simple, slow-changing protocols that do one thing and do that one thing well. If we do not manage that, then this war will be lost.
Tony Hoare said it best: “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
This is the best summary of the whole security (and software) mess I know. And he apparently said it in 1980. Yet many coders still produce complex code and some even see nothing wrong with that and rather believe it shows how well they can handle complexity and how “macho” they are.
A few links I picked up on Slashdot’s (woefully incomplete) discussion on this. Everyone on Slashdot assumed this SSL exploit was discovered from peer review of code – no mention of Finland defense contractor and Google shenanigans I covered in comments above.
The relevant code and the fix – this is TRULY pathetic (and obviously deliberate – to allow a remote to control memory access with no checking)
Test your (any) server here (from comment here “In the quick tests I did on login.yahoo.com (used for Yahoo’s email and probably all other Yahoo services), I saw three different user’s passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!”)
This is probably the biggest web vulnerability affecting Linux ever.
UPDATE: There’s a more comprehensive test site here (from Yahoo’s article on the bug).
I think company in Finland is not defence contractor, they seem tomsell their fuzzers to everyone
Reblogged this on O Futuro é a Liberdade and commented:
É… acabaram-se as ilusões…
I must say I’m extremely disappointed by what I see in the ‘Linux community’ regarding its use and handling of the information I’ve presented in this series of articles. This doesn’t include everyone, of course, and many people on this blog have kept to an intelligent discourse (or I’m sure they know I’ll confront them directly). Yet elsewhere my articles appear, I see a dismal array of name-calling, dismissal, defensiveness, etc. “Oh, that NSA spying stuff is just paranoia!” Really?
For one, isn’t it just amazing how many people rush to defend the pristine honor of billion-dollar corporations and secretive government agencies, lest their actions be misinterpreted in the slightest? Those poor innocent victims with such unblemished reputations, they need our unending support and every benefit of the doubt! I’m sure some of these people are not genuine, and some just live woefully misinformed, yet many are clearly people pissing their pants, unable to face what at this point in time should be abundantly clear, even if you only subscribe to mainstream press. Shouldn’t it be utterly obvious that Linux is owned and gamed? Shouldn’t this be a basic assumption by now, rather than being some far-out claim requiring extraordinary proof?
And proof is another thing. I’ve been around on the internets for awhile, and never have I see grown people cling to “prove it!” like imbecilic children like these people do. It’s even a basic tenet of science that a theory cannot be proven, only disproven. Personally, I don’t even believe in the concept of ‘proof’ (or disproof) – there’s simply no such thing. Facts can always change or expand with perception, which changes interpretation. The best people can do is share with you the facts as they perceive and can reference them, as well as their own interpretations of those facts, and their ‘working conclusions’. Yet here in these discussions we see people clinging to the proposition that Linux is untouchable by the NSA unless categorical proof is provided, and nothing short of that can budge their absolute faith (such as even basic common sense). Since I see proof as an oxymoron, to me these people will be demanding proof well after they’re living on dirt, eating dirt, and surrounded by barbed wire. There’s simply no reaching them on anything that requires genuine intelligence (no pun intended). Beware following them where they’re headed – it ain’t pretty.
As a result, as a person bringing these facts forward and piecing them together, sharing my own working conclusions clearly and honestly, I am compelled to address ridiculous attacks and nonsense denial over and over again. Instead of quickly forming a consensus that yes, all of this is highly plausible given our world, and quickly moving onto the stage of discussing its ramifications, possible solutions, etc., we are often held in a state of turmoil. Eventually one does come to look paranoid and defensive, just addressing such people. And this disruption of consensus-forming is exactly what paid disruptors are alleged to focus on – and clearly it works.
I also see these attacks against Julian Assange, and frankly it has served to raise my opinion of him. I used to have strong doubts about him, yet seeing peoples’ reactions and abuse, and the way they defend corporations like Google and Red Hat, the NSA, and Linux big shots, against his very sensible theories and explanations, it has given me a new respect for him. I don’t know if we can know what anyone’s true motives are in this business, but what he presents surely far outweighs the utter drivel that people launch against him, and the way they believe the press, which couldn’t tell a truth if it tried. To him I say, thank you Julian Assange!
For people who arrogantly like to consider themselves intelligent, I must say that much of the Linux community seems truly witless. It’s hard to say what the actual numbers are, because the most vocal people don’t necessarily represent the majority. For example, this article has been read by several thousand people thus far, and a handful have left comments here and elsewhere. What I notice in comments, especially outside of this blog, is people failing to address exactly what I’ve described above – the utter stupidity of people still denying basic plausibility of these intrusions and their mechanisms, and the lack of consensus-forming. Silence. That’s a good response to fascism and totalitarianism, if you want it to continue and grow. And that includes Americans, who perhaps think the NSA is ‘on their side’. Really, do you control them, your jailers?
At any rate, I’m one who believes in allowing others to think as they like. I mainly show you what I see, as clearly and honestly as I know how. But overall I would say the Linux community, and world population in general, needs to smarten up a whole lot, even in terms of basic survival. Get past the denial.
I have to admit that one of the things I like least about Linux are the people. They seem to attack each other continuously, instead of being capable of discussing things calmly and clearly – raging egos. Perhaps this is the world in microcosm, but in other areas of my life I don’t find people this way. I’m not claiming to be a great diplomat, and I don’t take abuse kindly – if you’re going to disparage me, especially on my own blog, you’re likely to hear just what I think of you in return. Yet that’s not who I like to be, and I don’t like who I tend to be among people in Linux. Part of this is that Linux people are largely corporate workers, indoctrinated into a system which I rejected long ago. I guess it’s the only way they know how to communicate and interact – arrogance, bickering and petty attacks. Disgusting.
All of that being said, I’m pleased to see that people are bringing some genuine forward-thinking questions, suspicions, and theories here. I try to confront and chase off trolls for just this purpose, even if it gets ugly sometimes. Thanks for participating, and keep thinking, theorizing, and planning, even if it appears the people around you are fools. We’re not all fools, and I hear from others in email as well, who won’t necessarily post comments. We’re not alone in seeing what’s happening, and in desiring genuine change. While it may seem hopeless at times, the only way is forward.
[…] Julian Assange: Debian "pertenece" a la NSA [ENG] […]
Pingback by Julian Assange: Debian "pertenece" a la NSA [ENG] | April 10, 2014 |
[…] See on igurublog.wordpress.com […]
This blog post is a classic example of how conspiracy theories are developed. It sounds fairly plausible if you don’t know the details or the people involved, but in fact it’s largely nonsense. Debian is many things, but ‘engineered by nation-states with backdoors’ is not one of them. The SSH RNG cock-up _was_ a mistake by a developer after confusing communication. I was there. I know the developer concerned pretty well. Saying it was “was clearly sabotaged – a known fact”, just shows that the poster is not familiar with the people involved, or suffering from conspiracy ideation. Similarly, Red Hat may now be a large corporation, (which sells a lot of services to the US military), but the geeks who work there work on free software as part of the community, to our standards, which are actually relatively high in comparison to much proprietary software, which is even worse. Yes, there are far too many security holes, because it’s hard to get right, and not enough time/effort/money goes into getting that stuff right, as opposed to writing yet more code. But it’s because it’s genuinely hard, not because people are being blackmailed, or due to deliberate malfeasance.
There is a lot Debian could do to improve its security (the main limitation on this is manpower – please come and help if you care about the security of GNU/Linux), but we do do a lot of things right too, and our independence from any one organisation is an important part of why it’s a trustworthy entity.
Yes, you’re all just a bunch of innocent, incompetent fuck-ups and it’s all accidental. We know that story already, and you’re not substantiating anything you’re saying with a single fact. You’re just making random, emotional statements. That’s easy to do. I on the other hand have provided many details, profiles of developers, links to discussions, evidence of intrusions, and explanations of mechanisms involved, here and elsewhere.
It’s not hard to get it right. If things are built simply, with careful, sane maintenance, it’s much, much easier. Code CAN be (and some is) accurate and bullet-proof. The reason Debian is a non-secure, increasingly complex POS is that its engineered to be that way, and I do know the details and people involved – quite well. This is not primarily a technological problem, it is a political and social problem. The Debian community is filled with corporate hacks with agendas to keep it growing less secure and stable everyday, and the idea that it doesn’t contain backdoors is laughable. I guess the NSA and others just completely ignore all Debian users then, according to you, and don’t infiltrate the community at all, like they do in all other such communities. How convenient and magical! You’re safe!
Maybe you’re just yet another childlike, naive computer programmer, or maybe you’re a liar deliberately deceiving people. While your trash may convince people looking to stay in denial – and today’s world is full of them – 20 years ago in security discussions you would have been laughed off the stage as the buffoon you are.
Using ridicule to discourage open and honest discussion of ALL possibilities, as well as theorizing on how intrusions are conducted, is truly insidious in today’s climate. And acknowledging that you are a personal friend of a developer who caused the worst security breach in Debian’s history doesn’t exactly add credibility, jfyi. Even if you are uninvolved, perhaps you’ve heard of the concept of people lying to protect themselves, even to their friends. Or perhaps the concept of ‘lying’ is too much of a conspiracy theory for you.
Keep lying to yourself and others – see where you end up with the road you’re on. The NSA is all just a conspiracy, and the world is a happy corporate lounge.
So why don’t you add grsecurity by default?
Just so you know grsec is not a magic bullet fixing bad programming https://twitter.com/grsecurity/status/453653467412717568
I use grsec on my system and it already shows some problems with current software: for example current open source opengl stack is written in a way that some binaries need to have write|exec memory (not even talking about closed source ones). Other problem is that more and more applications use JIT which seems to be getting popular and also requires write|exec while in most cases providing no clear benefit over interpreter based approach, expect being super fast in some benchmarks.
Again, secure kernel won’t defend you against bad programming.
Yeah, I know. Well, it seems they *might* be moving in the right direction https://wiki.debian.org/SameKernel
This is a speculation very much in line with this blog post: http://www.reddit.com/r/linux/comments/18q7nr/spender_grsecurity_author_linux_approach_to/c8h5ars
[…] It has also been picked up by The Ignorant Guru Blog, who’s interpretation was a more parochial but no-less headline grabbing “Julian Assange: Debian Is Owned By The NSA”: http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/ […]
Pingback by HeartBleed –Incompetence or Evil? | madra.net | April 10, 2014 |
This is an extremely interesting and relevant debate and I am very happy that it is taking place. I wonder to what extent we might be able to rely on the BSD kernel in order to avoid this influence from Red Hat. Can anyone here comment on the viability of BSDs given what seems to be growing corporate control of Linux-based derivatives?
I looked over the code for this bug and it’s such a simple thing it should have never made it into the source code. Any 15 year old kid programming in C would know not to allow the user to arbitrarily specify a length of data to be returned which differs to the ‘real length’.
How many more holes like this are there ?
I’m a Linux user. Far from screaming “This cannot be happening!” I realize the seriousness of the situation. What can I as a person do with a system that is being deliberately compromised by forces far powerful that I ever thought? What can this example tell us about the vulnerability of ‘open’ systems of governance to tampering by the elites?I’m baffled, horrified by the implications of this revelation.
First, thank you for saying so! It’s encouraging to simply hear ‘me too’ at least once in awhile, and I know it’s not easy for non-programmers to jump into such discussions. Really it’s not easy for anyone yet.
This is largely not a technological problem. OSes could be built very differently if there was social, political and even financial support for such changes. Raising these discussions widely, and keeping on track and focused on the real problems they present is very important. No deep technical knowledge required – just repost articles like this and call out the people and trolls who try to downplay them. Be vocal and insistent. And remember, what you use, you support. Use and where applicable buy (or donate money to) developers who are helping the situation. Promote change.
Developers are actually handling this very, very poorly overall, despite their technical knowledge, or perhaps because of it. They can’t see the forest for the trees, they’re set in their ways, and they don’t know how to solve a problem like this that isn’t black & white. Users need to take the lead.
This is a hot time for this because awareness of this issue has broken into the mainstream. To some extent, I believe the NSA and others want us to know we’re being spied on, as a means of psychological control, and also as a means of distorting what they’re really doing (which goes beyond mere spying into manipulation and large-scale psyops – these are the people who start wars through social and conventional media manipulation, etc.) Yet don’t let that stop you from discussing it. Just be mindful to stay focused. This is not really about privacy. As you observed, it’s about opportunities for open, transparent government and economics, communication, etc.
I think what we mostly need at this point in the process is more honesty, and more, not less, theorizing. As the flow of ideas and views opens up, consensus does form – this is why ‘they’ try to forestall such open discussion. Greater awareness of how we’ve been gamed, and less denial. Only by directly facing this reality we now live with, can we have any hope of changing it, and your attitude is exactly what I like to see. That’s where it starts. Start telling the truth.
I want you to know you changed my whole day with your questions – just giving me the opportunity to write a positive, non-defensive answer for a change has me thinking along much more positive lines – I’m excited by the possibilities. And I encourage others to do the same – how do you answer this? Give it a try.
Thousands of other people will be reading your comment as well in the weeks, months, and years to come (no exaggeration – this article has already had almost 20,000 readers in just a couple days, and my articles tend to have long lifespans as they propagate). The butterfly effect is not to be underestimated here. Many, many people share your concerns.
[…] [Πηγή] […]
Pingback by Julian Assange: Το Debian Ανήκει Στην NSA | April 10, 2014 |
I’m sorry, but this story would carry far more weight with me if the source was Snowden rather than Assange.
In that case, have a look at Wired (and similar reports):
Normally I wouldn’t even link to that Wired spin article, which goes on to tell us how the NSA is doing no such thing and there’s nothing to worry about, go back to sleep. They certainly would never think of bribes and blackmail, from Wired’s watered-down perspective.
Personally I think Snowden is a deliberate plant (perhaps Assange too), but that’s not to say some of what he’s revealing isn’t accurate and demonstrable. Regardless of the source, think for yourself, use common sense and extrapolation, and listen to what’s being said, rather than obsessing over who’s saying it. As a former cypherpunk, I can tell you that Assange had some very valuable insights in his talk. Where he missed for me is stressing the security of nation-states, rather than of people, collectively and individually. Regardless, he discussed many valid issues.
And when big names like this discuss these issues, like it or not it adds a lot of air time to them – awareness.
Now that this article is being circulated a bit, I’d like to point out a few community dynamics. I don’t obsess over this, but I do occasionally look to see where an article is appearing.
One thing I’ve noted about all these articles… as soon as they hit mainstream sites like Reddit or Slashdot, seemingly within seconds someone posts a comment to the effect of “I’ve never seen paranoia like that!”, “tin foil hats required!”, “that post is several years old”, or anything else they can say to dissuade people from clicking on the link. (And contrary to other comments, I make NO money when you click on a link to this blog, nor any money from this blog, aside from very rare small donations.) Who would be so motivated to have you avoid seeing this material and evaluating it for yourself, even the first few paragraphs?
With this article, someone on HackerNews (use hckrnews.com instead) convinced them to remove it because they said it misrepresented what Julian had said, and on Reddit they claimed my title was a misquote. Hair-splitting over a title is more important than this content? And for the record, the title it not a quote, it is merely a one-line paraphrasing of what Julian said, and I think that’s a perfectly reasonable reading. He was indeed talking about the NSA and other nation-state’s agencies, and how they engineer backdoors in Linux (aka own it), referring to Debian by name. Compared to the wildly misleading titles one reads in the mainstream press, adhering to their fine journalistic traditions (ha!), trying to censor this article over such a ridiculous point is beyond deceptive and egoic, it’s sinister.
Further, in my opening paragraph I describe Julian’s comments very accurately, and not once, but twice I strongly suggest that readers watch the entire video for themselves. Am I really trying to deceive you as to what Julian said? Rather, I want you to hear all of what he said.
Are such alleged people really on your side in all this? What could be their motivations for such desperate distortions of this content? These articles have people desperately working to prevent their going viral to a larger audience. Why?
If you give me one paragraph of time, I usually honor my readers’ time by telling you immediately what an article is about, before I dive into it. I realize not every topic interests everyone, so I save you the suspense.
In the case of this article, the fact that I included the OpenSSL bug has helped cut through some habitual denial, even though I just included it as a ‘current events’ example. It turned out to be a HUGE current event, and hugely relevant, which lends much credence to what Julian said. Score one for synchronicity.
Well, with everything being monitored, it is logical to use that information for “crowd control” measures. Let’s assume this URL got put on some sort of “watch list”. Not by people but by computer algorithms. If it appears anywhere on the Internet, the monitoring detects it and immediately Eliza bots start posting some counter-propaganda, not people. People aren’t required anymore for controlling lowly peasants on the interwebs.
Complete monitoring of everything on the Internet is required to make this work.
Since Siri electronic mass communication is broken beyond repair. You can’t decide anymore, if you’re talking to a person or to a army of spam bots…
lol Eliza – haven’t heard that name in awhile.
Actually you bring up a very good point from systems engineering. For a control system to work, it must have feedback, eg it must be able to measure what its controlling. In order to control a society with precision, you need to be able to monitor/measure that society in fine-grained ways. I have viewed this as the reason that the NSA bothers to tap Grandma on the phone talking about her cookie recipe, and distributes cellphones (with cameras) globally, even to 3rd world nations. They may not have food, but you can bet they’ve got cellphones. The NSA wants it all – the more data the better. With all that data, it’s then easy to see the effect of eg a media article on what people are saying and doing, and then craft more effective media articles/events. From there it doesn’t take long for precision control to evolve. This probably explains how people are so readily programmable these days – it’s really startling at times. For those of us who have been around for awhile, seeing reaction/behavior patterns today is like living in a weird scifi movie. And from your Eliza reference I suspect you have been. ;)
That is exactly that I suspect is happening here.
With Facebook/Twitter being the most important control tools, while YouTube provides distractions to inhibit thinking.
For feedback processing it needs access to instant communication
-> Whatsapp, now owned by Facebook.
Now add a virtual reality headset to the formula
-> Oculus Rift, now owned Facebook
…and you have all ingredients needed for a great dystopian sci-fi horror movie…
Interestingly the Linux community is controlled via Google Plus. Almost nobody else uses that.
Speaking of scifi reality:
Britons need to eat fewer baked beans because of impact of “smelly emissions” on global warming, peer warns
lol I actually checked the article date to see if it was an April 1 article – no such luck. Am I in a reality contiguous with 1980 or have I hit a quantum filament somewhere?? The House Of Lords certainly has their priorities well in hand.
This! comment! was the most interesting and frightening thought I’ve read in a while.
I’m not sure where to start with all of this apart from knowing that sinking feeling that things have been wrong in the Linux “community” for sometime and finally been able to step back and see the bigger picture. One issue is lazyness, things are easy to set-up and install so we don’t pay too much attention to what is under the hood.
A while back there was some local funding to promote open source it was infact a way of diverting money away from Linux and small Businesses promoting open source including its values to other interests who I would say promoted open source “lite” and that’s what we have sleepwalked into Open Source “lite” a term that’s been co-opted by Microsoft and partners to dilute its original intent.
Have you seen this yet? Former Chief Security Officer for Microsoft the Chairman of the Board of Firm Behind Heartbleed http://techrights.org/2014/04/08/howard-schmidt-codenomicon/ it helps put all the pieces of the puzzle together.
I need to put my thoughts together coherently and hope get something blogged in the next week or so, thanks for taking the time to put up your thoughts about this, it is important and there are many users and developers out there who have had enough of this cr*p
Interesting! Strange too. Codenomicon is a firm in Finland, normally somewhat freer and wiser. Yet this shows how, just like execs move from Big Pharma to the FDA and back, these insiders are all connected and move back and forth internationally. The whole established security community is owned, which is why we need to separate from it for any real security. Above in comments it was revealed that Henson who approved the Heartbleed bug code is a major developer in OpenSSL – establishment, to the point where some establishment developer called me a troll on my own blog for demanding his ejection from our OS.
As for the timing, I did note that, although not many of the mainstream press articles mentioned Linux in describing the Heartbleed bug (as is typical – they hate to mention Linux). Yet of course IT people clinging to XP know of Linux without the articles, so this is indeed a shot to it. Of course some of us know that Windows is no better, but this definitely was a (well-deserved) shot to Linux’s reputation. Linux people need to get off their high-horse and start paying attention to details, as you said.
And to time such an event, this exploit would of course have been known, another wild coincidence in this story. I’ve read enough alternative media conspiracy theories to recognize how these coincidences involving large corporate execs, etc., are not uncommon. Often such events are also arranged so as to accomplish multiple goals. This could have represented an intel war, with Microsoft trying to keep the XP crowd. But its hard too believe Google/NSA would sacrifice their reputations willingly. I guess Google got to look like the finder of the bug, at least. It does look like some conflict among intels from this. They’re getting very bold – shows they don’t even care if they’re outed.
I don’t know that we need to understand it all – all we need to understand is to get them out of our OS! And that includes Henson/OpenSSL, and other establishment hackers implicated in this intrusion. It shows how Linux is indeed owned/operated by the corporations (which implies govt agencies), and is completely at their mercy.
Thanks for the link – drop a link to your blog if you write some on this.
A little off-topic here, but since this isn’t getting much press, and it’s rather unique: some US state governments are threatening to turn off water and electricity to NSA facilities. Probably toothless but interesting to see. Can we shut off the water to Red Hat too?? systemd problem solved.
Wikileaks is officially denying that Julian literally said “Debian Is Owned By The NSA”. No shit. Are you guys really so unhip that you don’t know what Owned/Pwn means? :) Get out a little (oops, sorry Julian, bad choice of words ;) And it’s not a direct quote (hence no quotation), it’s a summary title. The first paragraph explains very clearly what Julian said.
I added a note to the article as some senior citizens seem to be choking on this – and I thought I was unhip.
And once again, it’s discouraging to see how many people find the smallest excuses to ignore and derail the important discussions here. Denial runs very deep in this community.
Of course, you are now officially a heretic by challenging the holy church of Debian. And you will see similar consequences people see, who dare to criticize the prophet.
The whole thing is stark ideologicalized right from the beginnings 20 years ago. I my view that raises suspicions, that there are greater hands in the background moving pawns on the chessboard. Debian served a purpose right from the beginning and it is not the one, they tell us in their “manifest” bible.
Everytime I read an IGuru post, the more It reads straight out of Faux News. A neuron exploded in my brain after reading this.
[…] шокирующая (лично для меня) новость от Ассанжа, что Debian принадлежит АНБ. Правда от Wikileaks пришло пояснение, что Ассанж не это […]
Pingback by Ежедневник kvarkson'a | 8 - 12 Апреля / Не космический | April 12, 2014 |
Bloomberg: NSA Said to Exploit Heartbleed Bug for Intelligence for Years:
While I recommend reading this mainstream news article for clues, keep in mind that it’s also spin. There is no mention of even the possibility that the NSA created this backdoor through bribes and blackmail, when analysis of the vulnerability indicates that is almost surely the case. Admitting that they knew about it is probably just a way to divert attention from the details of how it was created (which this article avoids completely of course).
If you take one thing away from this Heartbleed bug, get this: This episode demonstrates that mainstream Linux developers will NEVER admit that any backdoor ever exists as such. They will ALWAYS claim it was merely accidental and unknown, regardless of how obvious the intrusion is. Evidence doesn’t get better than this Heartbleed bug, whose detection was also concealed by breaking normal malloc behavior. Unless you record the bribe taking place, which is virtually impossible, you won’t see a better or more obvious example of a deliberately engineered backdoor.
What does this mean? It means that no one will ever be held accountable for these security failures (in this case in the corporate/govt security establishment that maintains OpenSSL), and there will be no movement away from such people and organizations that Linux/BSD uses exclusively for its security apparatus. Linux is owned.
The intellectual discourse on this issue has certainly been popcorn and blanket worthy. But what on earth do we do from here? What are the solutions? Many of us acknowledge, nod and agree with the essential arguments that there are larger unseen hands stirring the cake mix. From a practical point of view these are my questions: 1) What distros are actually doing something to combat the state of affairs?; 2) Which groups or teams have demonstrated caution or are aiming to be trustworthy?; 3) Is this an opportunity to see what other open source operating systems have to offer?; 4) Where should we direct our votes, money and time to breaking stemming the flow of craziness? The intellectual masturbation is nice from time to time, but what should we be doing besides sitting around with the lube?
I too welcome other’s replies to your questions. I have a few.
Most people who work in Linux are good at dealing with specific technological problems, but this is largely a political/people problem for now, and they’re really blowing it, mostly because they can’t let their egos own the facts of how bad the situation is. They just defend and deny, which is no way to get solutions started. As someone who has been investing a lot of energy to bring visibility to these problems, I can tell you that it’s very challenging – you’re merely constantly attacked as a lunatic for discussing it in any intelligent way, although this Heartbleed thing has certainly shut up a lot of them for now (but not for long).
I think every usable OS is effectively owned at this point, and worse, being engineered to be effectively closed. As PHK suggested, we need to start designing and writing code like grownups, and (I add) get these corporate stooges out of our code. For people interested in these questions, I strongly suggest taking the 30 minutes to watch PHK’s talk.
Also, in the myth department, I have repeatedly detailed how Red Hat is almost exclusively engineering Linux, and their deep government ties. This is a simple fact – they control the commits, design and control things like udev and systemd used in all distros, etc., and have the US military as their largest customer. Yet I routinely see my posts being categorically denied by developers. They just can’t seem to ‘get it’, but you notice they address none of the details I raise. Give them some wake-up calls, because these are the people writing Linux.
You call this mental masturbation, but theorizing and planning is essential. If people can’t even discuss these topics intelligently and get past the tin foil hat crap, you won’t achieve any consensus or development action on them. Yet the forces arrayed against this happening are very large, well-organized, and insidious. It is a very, very challenging problem.
I do apologize if I came across as being insensitive with the mental masturbation comment. This wasn’t intended. I guess after reading something like 30 blogs and 15 different articles on prominent media outlet son the issue, it seems frustrating that no one is talking about solutions that people can take apart from changing passwords and then going on about their daily activities. For most this may be fine, but some of us would like to do more and take proactive measures in the event (inevitability) that this happens again. The Fosdem talk mentioned previously was very good. On another note, apparently too the folks over at Gentoo said their distro wasn’t affected by this. They also seem to have no plans for integrating systemd. Could they be doing something that we might want to pay attention do?
Neither of that is correct. First, gentoo was affected, but as I said… only if you actually enabled the USE flag “tls-heartbeat”. USE flags in gentoo mostly control compile-time switches you would normally pass to e.g. “./configure”. Having the ability to disable codepaths you don’t need is in my eyes a good thing (e.g. try to remove dbus support from a debian installation…impossible).
Second, gentoo has systemd support, it is fully integrated. But it is optional. The default init system is still openrc.
A couple more articles worth reading and analyzing…
Behind the Scenes: The Crazy 72 Hours Leading Up to the Heartbleed Discovery:
It’s interesting that almost all mainstream articles on this bug report Google as the finder (and most news-absorbers will never hear anything but that). Here is glaring evidence that the NSA-affiliated Google already knew about the ‘bug’. (Assange and many others have detailed how Google is an arm of the NSA, as are Facebook, etc. Buyer beware.)
And the impact of this backdoor continues to grow beyond web servers…
Reuters: ‘Heartbleed’ computer bug threat spreads to firewalls and beyond:
Unlike others, not one thing about this event has surprised me or caught me off guard. Why? Because like all good security-minded people, I theorize, extrapolate, and use common sense to see what is being done. Really, it’s plain as day once you get past the need to deny, deny, deny.
Theo de Raadt doubting the integrity of IETF over the Heartbleed bug.
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl/Makefile?rev=1.29;content-type=text%2Fx-cvsweb-markup
Gentoo was not affected per se by heartbleed since we allow users to control compile-time switches. TLS heartbeat is an optional codepath and luckily I did not have it enabled on my gentoo server.
Further… I don’t think you mean debian messing up SSH. It was OpenSSL, see http://www.gergely.risko.hu/debian-dsa1571.en.html … and it looks more like an amateur trying to fix valgrind warnings. There are a lot of distributors who don’t communicate with upstream and add random hacks downstream, because they think they are smart.
Interesting on gentoo’s impact. They are definitely a community resisting much of this.
Your own link indicates the SSH problem (actually I think it affected SSH and SSL) was a Debian maintainer (of OpenSSL), and afaik only Debian was affected (not referring to Heartbleed but to the prior backdoor). The reality is hasufell, any sufficiently engineered backdoor can be made to look accidental, at least to people more than willing to pretend none of this is happening, and Kurt’s behavior was very suspicious (including trying multiple times to get it upstream even after it was rejected – he really wanted a change which he claimed had no functional value). As I said above, most people will NEVER admit an intrusion, no matter how obvious. They hide behind plausible deniability (in this case not even plausible), a very old trick that serious security and intelligence people deal with every day. If the Linux community hides behind “prove it!”, they aren’t making themselves any safer or less owned.
It’s also becoming very overt, where corporations are doing most of the engineering in Linux, corporations which clearly have conflicts of interest. Yet anyone can be bribed, blackmailed, etc., and anyone can lie and create deniability. You simply don’t know. But you can act on the results, putting bullshit aside.
Assange spoke in the original article’s video of the growing push in Europe and elsewhere to secure national networks. The Centre for Research on Globalization reports that Friday, the United States Trade Representative released a report stating that doing so will violate trade agreements.
Personally, I don’t think the answer will come at a national level, as such institutions are too vulnerable to these legal and political pressures. Any freedom, inside and outside the US, will come from strengthening encryption on the individual level – eg many secure PCs not subject to any central control. This is where creating a genuinely secure OS comes into the picture.
U.S. Claims Country Building Its Own Network to Protect Against NSA Spying Violates Trade Laws
The USTR report states:
You’re on to something here. With several governments in the EU (both regional and national levels) moving toward open source and Linux-based OSes specifically, its high time to make security a primary consideration. Perhaps its time to slow Linux kernel development down a bit and focus on fixing bucks, removing depricated features to reduce the size of the kernel and audit. This is essentially the strategy that the BSD groups take unless I am wrong here.
I agree, yet the kernel has been somewhat slowly and carefully developed compared to many ancillary components (openssl, udev, systemd, etc), used in all distros, largely corporate developed (Google, Red Hat), and largely responsible for the largest security problems. These components especially, which also greatly impact security, are being developed and integrated at a break-neck pace, often containing perpetually broken code. Any few exploits that are found are quickly recreated in the next release in yet another form. Just see the continuous stream of endless bugs coming from such projects. The new normal.
BSD has moved more slowly, but they too are impacted, as they were by Heartbleed (which was not a kernel-based intrusion).
Personally, I think a start from scratch with an entirely new, genuinely security-minded, simple and slow design is what’s needed. Yet for that to succeed, the solid social/political framework must exist, which at present it does not. Any such endeavors are hijacked, especially because the Linux community relies on establishment (corporate) developers for security(and just about everything).
Yet slowing down is critical.
MirBSD was not affected by Heartbleed directly. I chose to stay with an older OpenSSL version, and it has paid off at least five times by now.
But yes, Red Hat and systemd must be stopped.
If this truly means that Linux has to be built from the ground up, do you see the GNU/Hurd kernel becoming an eventual reality in this case? Should we be supporting is continued development?
I’m not the best person to ask this of, details-wise, but it’s a good question. I think Hurd is attempting to address this on the kernel level.
I think some limited things could be borrowed from Linux and BSD. Graphical (X/Wayland replacements), and the whole video driver issues, represents a great challenge, as closed hardware guarantees intrusion. If you really want security, I think sacrifices will need to be made, especially early on. Maybe start with a truly secure console-only, text-based OS, running on open hardware, and be mindful not to pollute it at lower levels. Maybe a 3D printable secure system. :)
This isn’t to say every user-level app needs to be developed as bullet-proof, but you want a very secure, simple base to work on (kernel and device support), which also provides genuinely secure, very slowly changing crypto libraries. And leave it up to the user what programs are included, which may contaminate it. Sort of like what Linux pretends to be, except that the system itself is pwned in Linux at a very low level, and the CPU, display, printer, and networking hardware is pwned as well, so the user has no real choice in the matter.
We’re a long way from any such thing, but in terms of long range planning, this is how it could work. And really it’s not that difficult code-wise, except politically, and the lack of hardware.
Maybe the solution will look more like an Apple device, where the hardware is fixed, and the software is hard-coded for it. Sort of a military-grade pad for civilians, with a new model released every few years, with very slow and careful development on all levels, from software to hardware. And providing secure ad hoc networking capabilities in addition to internet/cellular 4G/encrypted-voice/encrypted-IM etc capable.
Btw the first open hardware laptop is appearing this year.
And new, sane regulated standards, as PHK suggested, have to be part of this, also simple and inter-flexible. eg separating networking hardware/bandwidth from protocols, etc. Just use a bandwidth or carrier for what you want.
Wouldn’t you love to have a device that was encapsulated with secure communications, no real setup or maintenance required, just critical updates? And developed by people you genuinely trusted, with lots of eyes on it. I think there would be a real market for such a thing. Even if it started out as just a secondary secure mobile device to your main games & flash PC. If the internet goes out, your open-pad could establish a secure neighborhood ad hoc network just like that, which could connect to other nearby networks of the same type (there are already things like this), effectively replacing the internet, at least for basic blogging (news), IM, etc.
But you have to understand that the whole NSA-crowd (well embedded in the Linux establishment) would try to sabotage this at every stage – it’s their worst nightmare. You would need a collaborative effort among an aware population to sustain it.
No. The solution is to migrate to more secure languages, or to write systems that can be statically analyzed better than what we can do now. Code reviews are not a safe way to avoid bugs, but static analysis is. It is a step towards formal verification.
In all of these bugs you can see how techniques from formal verification would help. Take OpenSSL as an example. If the developers of OpenSSL understood that it was critical that the valgrind tool should be usable on their software we would have neither the Debian bug nor this bug.
The developers of OpenSSL should have made every effort to document how valgrind should have been used in their project. If they couldn’t get it to work out of the box, they should have had an option for it, and comments in the code saying why they could not have the invariants that normal C code has.
The mindset that developers can fully understand the code is similar to a view that writing things in machine code is safer. The way we get safe code, is to be able to express very strong invariants in the code.
Similarly, bugs in the linux kernel has been found using static analysis. These are powerful tools that must become part of our toolset. However, to really make secure software, we need to switch to languages where we can actually express precise invariants. When we can do that, the system/compiler limits the possibilities for bugs enormously.
In the CS theory this is called type systems, and when the type systems get really powerful, they are called proof assistants.
If you want to learn what is state of the art, where both high performance and safe programs can be written, look at the Haskell language or other functional languages.
I agree fully – C is a nightmare in this regard, and should certainly not be used for security-related code EVER, regardless of speed. C (or a language like it) is for driver-level hardware interaction only, in very small units.
It continues to be used where it should not be, as in OpenSSL, precisely because it is an inaccessible, complex language where things can be hidden. The last thing they want is a nice clean sheet of paper that shows every mistake and exploit. They want shady. They also use it as a ‘priests language’ (elite) to restrict access to ‘commoners’. (Priests historically used to be among those who could read and write, and knowledge was kept exclusive.)
In that respect, not much from Linux/BSD is reusable. Yet crypto is complex by nature, so you’ll always need a robust review process, regardless of language or tools.
That sounds reasonable. However, I think a lot of people have more problems to understand functional languages than C.
I would be very surprised if haskell starts to replace C in those fields… not going to happen IMO.
It should be noted there are two very different fields here. Crypto is largely mathematics, which lends itself to a highly functional language. C is very inappropriate IMO – like doing your finances in binary.
Networking code (what it is doing in a crypto lib in the first place?) is a whole other beast. Neither is best written in C, except for very low-level hardware/network drivers perhaps. C was never designed for that kind of code – it’s only one step up from assembly. As we see In Heartbleed, it causes trouble. Although Heartbleed is such an obvious conceptual failure it would have been present in any language – there is no avoiding outright stupidity/malice. Though C was good for hiding it from tools that may have analyzed the failure.
If networking code wasn’t in the crypto lib, secret keys wouldn’t have been vulnerable. It’s just a mess. An NSA delight.
The programming language is not the issue.
The problem is that 2/3 of the population just can’t program in any language and will never learn it:
http://blog.codinghorror.com/separating-programming-sheep-from-non-programming-goats/
And exactly those incompetent people are planted into open source projects with paid programs like “Google Summer of Code” or “Outreach program for women”.
Those programmer pretenders, who don’t have a single clue what is going on, are the perfect source repository “maintainers” to feed them with backdoor patches. Dilbert principle at work.
There is a fight back within the distros it would seem and certainly an awareness of what is happening to force things through, Its worth looking into what is happening with Debian for example https://lists.debian.org/debian-project/2014/03/msg00062.html someone tried to get “Proposal – preserve freedom of choice of init systems” through
In other news there is talk of the Gnome foundation running out of money….
Can’t say that I am sad to see the GNOME situation. They made poor decisions, alienated their users and didn’t care when those users voiced their concerns. Xfce, the customizability of KDE and other destops are far more sane at the moment. GNOME needs to reinvent itself and fast if they want to remain relevant. (I’m also waiting to hear confirmation that GNOME is fully under the control of Red Hat, perhaps they are intentionally running them into the ground).
> I’m also waiting to hear confirmation that GNOME is fully under the control of Red Hat
In case you or others haven’t seen it, digest this article, keeping in mind that all the developers involved are from Red Hat. If GNOME, with its Red Hat/Google connections is running out of money, it’s by design.
That proposal, and all others, got dropped. I still don’t quite understand why. I’ve not been in the loop. Debian seems to have apathy/inertia after four people decided against four other people and won, which other developers now (in the face of absence of follow-up proposals, except Ian’s which got rejected by CTTE) say it’s a “project decision” and throw that into other developers’ faces.
I’m unsure what to do. I could just package BSD init for Debian, mostly for myself. But I fear Debian will go the Arch Linux way and remove sysvinit support after jessie, making systemd mandatory. Maybe I would be able to circumvent that with my own (not uploaded) init package, maybe not, but in either case I do not feel I should “support” Debian’s bad decision.
Occasionally I do hear (privately or publicly) from other Debian Developers how uncontent they are with the situation, but we all feel powerless to change anything now.
I suggested the systemd people just fork Debian and do their, ahem, innovation in the fork, and leave us people in the main distro alone. (The other way won’t work obviously, if they are going to positively remove support for nōn-systemd.)
We may see yet another Debian fork, but NSA has measures to disrupt and corrupt such movements, should they become an issue. Especially Debian with their pseudo-”democracy” is very vulnerable to such hostile takeovers.
The Gnome Foundation has aparently wasted money on non-core projects and in some respects widened the agenda to social inclusion etc etc things the get in the way of the Gnome Desktop (I suppose similar to the way the Mozilla Foundation as been sidetracked into political arguments rather than just promoting the software projects they are responsible) .
Sad to see the direction of GTK3 & Gnome but yes they seem to have brought it upon themselves (by design?!), I have to say I am quite please with the work done on mate http://mate-desktop.org/
The NSA has been in elbows deep since Bletchley Park. They own 99% of all OS’s with the possible exception of OpenBSD. Only because DeRaadt pissed off DARPA.
They were there when Ritchie and crew created Unix.Most of them now work for Google(NSA front) on the GO language.
How many NSA contractors or acadamia contribute to Linux(SELinux),FreeBSD(TrustedBSD),Apple or Open Darwin. Hurd is based on MACH which already has it’s NSA MAC installed.
Stallman pimps his EMACS as SELinux friendly and Linus hardcoded SELinux way back in the 2.6 kernel.
An easier question would be who is not on the payroll.
One option is for a group of coders away from the US to come up with a completely independent OS.
As a gentoo distributor I think that is pure nonsense. Maybe OpenBSD is even a bit overrated… e.g. none of them have stumbled upon the 100+ Xserver bugs that were found throughout the last year (the guy who reviewed it was at CCC congress in hamburg, germany last winter, there is a video on youtube).
Source distros who are open to their community, have strict public review policies and don’t distribute precompiled binaries per se, are pretty difficult to infiltrate (and OpenBSD is probably one of them).
Unless you are chatting about the general “bugs everywhere” FUD… then you have to remove OpenBSD from your list as well. And an “independent” OS (we already have them) will not change the fact that we will see bugs and maybe even purposely written backdoors in open source code… and the fact that it IS open source is our best chance to face that threat.
So don’t dream about stuff, start reading code.
Freedombox Project almost ready
http://linux.slashdot.org/story/14/04/16/1355220/all-packages-needed-for-freedombox-now-in-debian
Until proven otherwise, I would classify this “freedombox” as NSA trojan horse to wiretap your private communication.
Sorry, I don’t fall for it anymore.
Please justify your assertions here. Links? Why would this be a trojan horse?
Did you read the headline of this blog post?
I’m glad at least one person got the irony, My talents are wasted here.
Conceptually FreedomBox looks like it has some good stuff – making it simpler to use privacy tools and bring them to mobile devices. And threat assessment is always important in choosing security tools. Such tools may help eg dissidents avoid persecution by local and national law enforcement in their country, or having their business sabotaged via espionage, even if still vulnerable to the NSA and other intel. Yet the limitation must be noted too – using Debian (or any Linux) as a base is like building on quicksand, too many unknowns. Perhaps it’s a start that could move in a better direction. In many ways it is indeed a trojan if it fools people into thinking their communications are more secure than they are.
Really a ‘freedombox’ needs to somehow treat the very host it runs on as hostile territory, encrypting its own memory, etc. Not sure this is feasible when your kernel is pwned though. Notice that selinux goes beneath the kernel. A genuine security/privacy encapsulation tool would probably need to do the same, and forcefully keep everything else running on the machine out of its space, perhaps while also having access to the rest of the kernel for I/O and network access. I would think such an approach would be easier than trying to make the kernel and all the apps in Linux a secure environment. Instead create a hardened micro-kernel within the kernel. You’d have to assume that all your conventional kernel-based I/O and network access is pwned, but that’s a good assumption anyway.
Is it possible to encapsulate the kernel for regular use and keep personal information private?
It comes down to physical access. Don’t keep personal info on a network-capable piece of hardware. What most people call ‘personal info’ is really stuff they get/share online, but they want to limit access – a tunnel or restricted channel. This creates a more complex problem, but encryption with secure endpoints is the solution. What we mostly lack are secure endpoints.
Think of it this way… you have two computers, one online, and the other with no network connectivity. You ferry some information between them using a USB stick (VERY carefully, being mindful of content-viruses, etc.) Thus you control what goes online, and if you encrypt the info on the connectionless machine before moving it, you have good endpoint security.
Taking that to a hardware level, you could add a chip to a computer that has its own CPU and memory, with maybe USB slots for a USB encryption key, keyboard and storage, isolated in hardware from the rest of the machine. It can take control of the display when needed (or have a simple LCD display of its own), so you can choose what info to move out of the safebox into the regular storage. It could also create channels for encryption – basically it could handle your crypto library and keys, which the normal kernel could make use of. So you’ve basically reinvented your two machines on one board – physically isolating access yet on the chip level. It could even be a plug-in card or USB device.
If you trusted your CPU manufacturer, you could build this with a single CPU machine as well using a custom kernel, protecting some memory (or having some separate memory), isolating some I/O access from the kernel at times, and timeslicing access to the CPU, such that two virtual machines would exist.
The advantage to such an approach is that you wouldn’t have to try to reinvent all of Linux, display drivers and other I/O, apps, etc. in a secure way. You just need to create a safebox that handles crypto reliably, and offers genuinely offline, restricted storage, all on one machine. Maybe a little LCD display and keyboard just for accessing/configuring your safebox, with the rest of the machine treated like WAN territory and run by a conventional kernel. The safebox would handle your endpoint security. That’s really what’s missing in civilian crypto.
As we saw in Heartbleed, OpenSSL and similar endpoint garbage leaves your keys and data waving in the wind. It needs physical access protection on some level.
Any Richard Stallman reaction?
Not yet, I’ve have been looking for one.
Last I spoke with RMS, he was still deeply in love with GNOME and Red Hat, even though I clearly explained the GNOME3 fiasco – I get the impression he’s a fraud (and coming from MIT, that’s easy to believe – Recruitment University). The whole GNU is merely there to ‘stall’ evolution of free tools – I’m sure they get a laugh out of his name. I wouldn’t look for help there – Google and Red Hat pay his travel expenses.
The actual title of this post should read ; “Linux owned by the NSA”,
From the NSA website,
Researchers in the National Information Assurance Research Laboratory of the National Security Agency (NSA) worked with Secure Computing Corporation (SCC) to develop a strong, flexible mandatory access control architecture based on Type Enforcement, a mechanism first developed for the LOCK system. The NSA and SCC developed two Mach-based prototypes of the architecture: DTMach and DTOS.
http://www.nsa.gov/research/selinux/background.shtml
This about Secure Computing Corproation;
The company also developed filtering systems used by governments such as Iran and Saudi Arabia that blocks their citizens from accessing information on the Internet.
The Tunisian Government bought licenses for Secure Computing’s product Smartfilter.[10] The Tunisian Government is generally recognized as having a poor record when it comes to The Right of free expression.
http://en.wikipedia.org/wiki/Secure_Computing
They were bought out by McAfee.
McAfee has acquired Secure Computing, a global leader in enterprise security solutions.
http://www.securecomputing.com/
Who owns McAfee?
http://arstechnica.com/business/2010/08/why-intel-bought-mcafee/
By the company who re-introduced the Clipper Chip.
http://en.wikipedia.org/wiki/Trusted_Platform_Module
Any questions?
I forgot something;
DTMach was for the Mach kernel, which is what GNU Hurd is based on.
See, I knew I could get RMS in here somewhere.
And this;
Improvements to the Custom Themes system (M-x customize-themes).
Unified and improved completion system in many modes and packages.
Built-in support for GnuTLS, GTK+ 3, ImageMagick,SELinux, and Libxml2.
http://www.gnu.org/software/emacs/
Why would you endorse SELInux if you believe in free software?
NSA backdoor discovered in 1999 in Win95
http://www.heise.de/tp/artikel/5/5263/1.html
What SELinux/TrustedBSD/Flask can do;
With Flask, even the root account would not necessarily have total control over a machine. ‘Because it is a centralized policy for the entire system, even though multiple users are on the system, none of them can change the security posture of the whole box,’ Loscocco said.
http://gcn.com/Articles/2008/07/18/Security-is-no-secret.aspx?Page=3
I know this is probably going to degrade into ‘everythings pwned’, but Plan9 has been mentioned again since its been GPLv2′d: http://tech.slashdot.org/story/14/02/16/0319238/plan-9-from-bell-labs-operating-system-now-available-under-gplv2
This is a research OS intended to be the successor to UNIX, has a real-world derivative called Inferno.
Interesting. Basically the needs of security and the needs of gamers and such are divergent. Security needs a console-like display and highly restricted memory (slow and primitive), while many apps want fancy displays and fast direct memory access with rapidly changing features. I don’t think a single kernel design can serve both well. The security nightmare that X has become being one point of reference, and policykit/systemd another. We need to grow an ‘organ’ in the body Linux (or body PC) for endpoint security.
Inferno is a progression of Plan 9. Many of the old school Unix programmers now work for Google on the GO language.
And *that* is so utterly sad. And (like Linux kernel people using Google+ all the time) totally inexplicable, too. I smell another part of the conspiracy there.
Go isn’t good. It’s not better than Plan 9 or Inferno. It’s what they cobbled together for themselves, and/or as distraction for others, especially those who jump on all latest hypes. (Connection to Poettering/Sievers.)
I have investigated this subject for about a year now, the only OS’s not obviously compromised are OpenBSD and maybe Minix. There might be a few like Haiku also. I have now turned to small assembly based projects like MikeOS, BareMetalOS, Kolibri and NewOS. Not that any are better than the other.
I don’t think there is any(spy)nterest in Plan 9.
Like I said before, the NSA in one form or another have been in the computer business since the 1940′s.
With your money they can afford to hire(bribe) the best.
This will be a tough act to follow but don’t give up.
I think you’re deluding yourself wrt OpenBSD.
We (people) don’t need to beat the NSA at their game, we need to change the game. Keeping secrets is a very difficult business, and not much good comes of it. I’m much more interested in open cryptographic technologies, something the NSA cares little in developing.
IOW, use crypto to stop elections and finances from being gamed. Support genuinely open and verifiable polling, open and transparent monetary systems (so 99% of the people aren’t living in subjugation to a corrupt elite), and open intelligence systems that reveal abuses rather than keeping them hidden and using them for blackmail and control. Truth in media (whistleblowers), etc. That’s the real power of crypto – bring it all out into the open. If the NSA and related parties can’t game everyone, their stealing ‘secrets’ won’t matter much. And turn some of this spying tech against them – eg the cameras some police are now required to wear. Let’s spy on them – they work for us allegedly.
But of course some stable infrastructure must exist for that tech to work – you can’t be completely pwned. And admitting where you are pwned (Linux), rather than denying it for decades and living in delusions like children, is a good place to start. Assess security for real, and start building stuff that works for real. And get ‘insiders’ out of your PC/smart – all these corporate/govt developers that Linux is teeming with. Who needs them? Where are they taking you?
“It’s not too late at all. You just do not yet know what you are capable of.” ~ Mahatma Gandhi
It seems some people have still not understood this: if they want in your PC, they are IN. Period. No matter what OS. That was never the question and it will stay that way. Get used to it. The question is how easy we make mass surveillance. That is something we CAN change.
And FYI, distributors (including me) don’t code all the stuff they package on their own. And in case there is a distro-specific fork of any program… it is still a fork and probably 98% the same codebase. OpenBSD is no exception.
While there are a lot of things that can go wrong on the distributors end, it is still just one end. So yes, choosing the distro matters, (e.g. open community, open development/votes/procedures/code, choice, strict downstream policies, no binary packages,…) but it doesn’t make you invulnerable to security bugs (whether planted deliberately in open source or not). Meh.
OpenSSL Valhalla Rampage: http://opensslrampage.org/ – looks like OpenBSD has stepped up to exorcise OpenSSL – the site documents some of the shit they are finding and removing in their fork.
Yeah, but they’re damaging OpenSSL during this. They are removing lines of code they do not fully understand. (I know because I was in the very same line only weeks prior.)
They don’t want much, just everything – Google clarifying their spying practices… (as Assange and others have stated, Google is an arm of govt spying and data collection)
Google: We scan all Gmail messages
This all in response to a wiretapping lawsuit pending, where interestingly, people sending mail to Gmail users didn’t consent to having their emails read.