Kaspersky OS
eugene.kaspersky.com
eugene.kaspersky.com
(a) Linux is very insecure...I'm no expert but I'd like to see them prove their system is more secure than a Linux distro dedicated to security.
(b) Linux is the only viable option. There's plenty of other operating systems, some even focus on security (starting with the list of existing microkernels).
I do. Every time I read an article on a new "operating system" someone has released, it turns out to basically just be another Linux distribution, or a new gui/runtime environment running on top of the Linux kernel. Kaspersky took a step back and thought about their requirements, and decided to go with a microkernel architecture because they felt that was a better approach for security (a choice I agree with).
It's refreshing to see genuinely new OSs built from the ground up (open source or not), because it shows that not everyone is stuck in the mindset of Linux when they want to innovate in the OS space. That's not to say that Linux is necessarily a bad choice for many scenarios, just that it's great to see projects that don't restrict themselves based on the design of Linux (and, more generally, Unix).
It looks like a realistic assessment. General purpose operating systems ( at least the 3 most famous ones ) are built with ease of use in mind, not security. Even Torvalds admits it, saying that he sees performance as a top priority, and not security.
If Kaspersky OS is more secure or not, we will see in the future.
The underlying problem, IMO, is people. They just don't care about security, they want to deliver working device.
Also it's not clear how many vulnerabilities, used in real life attacks (like DDOS from IoT devices) are in latest Linux kernel? May be problem not with Linux, but with custom software or lack of updates.
OpenBSD project includes stuff like OpenSSH, time sync tools, an SSL implementation, and these are very widely used. Are those devices OpenBSD based though?
Similarly with BSD code, you can just use it and you only need to credit it with the code, so lots of OpenBSD kernel code will be in other systems with no user visible attribution. If MacOS kernel contains OpenBSD code, even big chunks, is it OpenBSD based?
With Linux, GPL means its kind of visible when someone is using it, and GPL encourages you not to integrate your software with it too tightly, so you get an obviously Linux based device with proprietary code on the top. With BSD, you can integrate much more tightly, only ever need to give out a binary blob, and no one would know you were using it.
That said, OpenBSD is kind of server oriented, and FreeBSD would be a more popular starting point for a device, but you might well crib OpenBSD for best practices.
https://www.genua.de/en/solutions.html
One can always strip out what's not necessary. One can also put it in user-mode on top of a secure microkernel with some services running directly on microkernel and some running in OpenBSD. That Kaspersky thought the choices were Linux-based or purely clean-slate shows limited knowledge of what's out there or a personal preference.
Kaspersky has a big-enough ego that I suspect his main goal is just having one of his company's and country's own to brag about. Especially if it ends up better in track record than something like Linux that's very visible albeit not made for security. That will actually be straight-forward if it's a Layer 2 or 3 operating system given how little they need to get right with one.
> The underlying problem, IMO, is people. They just don't care about security, they want to deliver working device.
> This unassuming black box is [...] designed for networks with extreme requirements for data security.
You can claim that nobody will buy Kaspersky's device, or that they did poor market research. But you can't claim that they don't care about security.
Their business is selling antivirus & other software, not security. They have no history whatsoever of building a piece of software immune to code injection by determined attackers. There are companies and academics that build stuff like that. Some were evaluated by pentesters of third parties. Kaspersky has neither that background nor evaluations by expert breakers. We should by default think they don't know what they're doing and the product is insecure until proven otherwise. Like always.
People often mistake "company in security industry selling security products" with "knows how to secure software or systems." They're two very different things.
If they're not liable in any way, then I agree it's nothing more than marketing to call it secure.
https://www.schneier.com/blog/archives/2004/11/computer_secu...
One example would be companies handling credit card information. If you leak a bunch of credit cards, Visa has to invalidate and reissue the cards, and the issuing banks have to spend a lot of money handling customer support. So they're motivated to punish companies when there are security breaches, and to write these punishments into the contracts.
Thanks for the article.
If they hack you, you can loose all your secrets, loose availability of your service in a way that customers leave, loose an election, or be implicated in crimes when your system is a proxy. I've never believed insurance would really compensate for such losses like it would a stolen TV or fire damage to a building.
"If you leak a bunch of credit cards, Visa has"
That's actually a good example. Both the regulatory and lawsuit-related penalties over mishandling PII have led to a boom of vendors offering solutions to make it easier. Still plenty of BS in the market but solutions are there due to incentives.
Then of course, I realized that by "Popular" he meant Mac OSX, Windows, and Linux.
Linux of course, we all know is a security mess because Torvalds refuses to deal with security issues.
Linux provides support for lots of security options, but the project's guiding philosophy is "don't break userland". This is 99% of the time what you see Linus cursing out other kernel contributors for. All of the possible options that Linus could _enforce_ would do just that. Heck, a lot of the security problems and blame have nothing to do with the kernel at all and lie squarely with systemd and how it's implemented. If these are dealbreaker features that you must have, Linux is not the tool for you. Your efforts are better spent working to improve OpenBSD.
"So LSM stays in. No ifs, buts, maybes or anything else. When I see the security people making sane arguments and agreeing on something, that will change. Quite frankly, I expect hell to freeze over before that happens, and pigs will be nesting in trees. But hey, I can hope."
He's typically very critical of security-related changes unless they are a massive improvement. I think characterizing him as "functionality over security" is entirely fair. He's not even wrong necessarily.
Companies that use Linux and need security will either get caught with their pants down or they won't. It's up to their level of preparedness and luck. I wouldn't underwrite that if I were an insurer though.
Those of us that care are already using something else.
I would actually argue that security doesn't depend on any one product, but instead a mindset, methodology, and toolbox. Defense in depth, etc.
So, yeah, blame Linus and others in that ecosystem who do everything but make a solid foundation. Contrast that to OpenBSD for monolithic or GenodeOS for microkernel approaches where they bake security in at various levels. MINIX 3 for reliability levels they achieved 10x faster than monolithic UNIX's did. You get what you focus on. :)
You should be shouting at companies who use it for applications where security is a must. That's where the madness lies.
I use OpenBSD and so should you :)
Due for a hardware refresh soon, and I will obviously be trying it again :)
It's even possible to do modern web stuff on OpenBSD. Erlang and Elixir run on it, as does Postgres. Phoenix framework pretty much works out of the box.
Is this Hacker News or slashdot?
Those get fixed. There are places where the kernel could be further hardened, but would break software.
Most of the security issues that we talk about have to do with process permissions and runlevel. The runlevel of systemd and it's various components is actually my #1 security concern. Has nothing to do with the kernel.
This has been done, but poorly and only for an extremely select few things. KASLR is just one example of a poorly implemented feature that pales in comparison to alternatives (completely subsumed by features in the grsec implementation, for example, since it only randomizes things like .text addresses. Maybe some of that got fixed.) Features like kptr_restrict can easily be subverted by a number of trivial infoleaks unless you back it up with a lot of other protections, etc.
Other things like __ro_after_init for read-only post-init memory have only recently been incorporated into arch/x86 (in the past few months AFAICS, so likely kernel 4.8+ only) since being available for nearly a year on x86 at least. I'm not sure if they fixed the fact __ro_after_init apparently didn't work on loadable modules. grsecurity's implementation is better anyway (allowing remarking variables as writeable for short windows), but I'll concede that extra power relies on KERNEXEC, which breaks some userspace things.
I don't think they botched the LATENT_ENTROPY plugin, at least...
If you actually look at the details, Linux has a pretty bad track record as far as "meaningfully implementing defenses" goes, considering how long this stuff has been around. It's better than literally nothing, I guess.
> There are places where the kernel could be further hardened, but would break software.
Uhhhh, sorry, but you need to do your research. There are plenty of places that could be improved without breaking userland at all, while still mitigating many classes of exploits. PAX_REFCOUNT is one example (a variant of which will probably soon go upstream in some weird way, of course). RANDSTRUCT, PAX_MEMORY_STACKLEAK, KSTACKOVERFLOW, JIT_HARDEN, RAND_THREADSTACK... If you're determined to fix the FPs, the SIZE_OVERFLOW plugin qualifies, too (it occasionally hits false positives, murdering an otherwise legitimate task, but this is a different scenario to a feature outright breaking userspace, and it's caught many bugs and can stop many actual exploits on its own).
There are probably at least a dozen major features in grsecurity that don't have to compromise userspace, and still aren't implemented in Linux, with no equivalent, and no timeline on the horizon. I'm not sure what to take away from this assessment of yours that the only remaining improvements will break things, other than you aren't really aware at all of what the current defense landscape looks like...
Furthermore, I really don't see how that link is relevant, given most of the more recent security features that went upstream, as well as many of the ones that will come in the future -- all originate in part from grsecurity anyway. Apparently, your position is that the kernel developers have already done all they can, and any further improvements else will break userspace, so systemd is definitely totes the #1 biggest problem now, everybody (non sequitur, but whatever). But when I bring up the defenses they could implement, but haven't yet, from the same source of the previous ones -- apparently I'm just doing some irrelevant posturing, or something? I find that funny. Maybe in 5 years when they've poorly ripped off more features and are still behind, you'll be moving the goalpost and saying "Any further improvements would break userspace", and it still won't be true in the slightest. :)
PAX_REFCOUNT is a non-breaking addition that would have stopped CVE-2016-0728 completely, for example, had it actually existed upstream -- it will soon enough, at least, as someone is working on it by porting the grsecurity patches.
The reality is very simple, even if you don't like it: upstream Linux is just bad at meaningful exploit mitigation, in many ways, and they have trailed behind what's possible for literally years. I'd also argue that some kernel developers seem to just have a complete, fundamental misunderstanding of what the point of the mitigations are, which is damning. One guy on the dev list argued with Kees Cook that people shouldn't bother with this shit, because we don't need to help "those bastards with proprietary modules be more secure" (Kees works on Android, so proprietary modules are just a fact of life, grsec improving their security simply being tangential), or help the people with out of tree kernels like the grsecurity team. It had apparently never dawned on him that mitigation tech could stop exploits that appear in the future. Like PAX_REFCOUNT stopping an exploit that would only appear in the future as time went on. This is mind-blowing as a position, for a developer of what is ostensibly one of the most complex projects in the world.
Anyone who has followed the grsecurity project for a while is pretty well aware of why they don't bother with upstream, and aware that upstream mostly reinvents their work, poorly. In any case, the given link is still irrelevant.
I'm going to go out on a limb and say you don't actually know much about modern memory corruption defense, or the landscape of modern kernel security and how it has moved forward over time, if this non-reply is your only answer to the examples I listed...
http://www.secure64.com/secure-operating-system
An older one that was pentested by the NSA with positive results reduced attack surface by using PPC embedded board, INTEGRITY microkernel, and carefully-coded state machines. That a small team made this shows both the big companies and startups could be doing way better if they cared.
As someone who has been paying attention to this space for some time I welcome anything new that increases exposure. It's cool stuff, and it's probably the future. However, there's a long way to go. Security doesn't stop at the operating system. In fact, the vast majority of security breaches occur due to misconfiguration, bugs, or good old fashioned social engineering. To really build a system that's "secure in principle" you can't stop at the operating system: you need to build a toolchain that makes it easy to build user space applications that are also "secure in principal" and you need to work on the HCI so the security model makes sense / isn't defeated by users. That's going to be a lot of work!
Now, we're looking at a top-notch team of OS programmers; presumably, they all have access to do that audit themselves, and at least some of them must be ethical and proficient enough to notice and refuse to ship a backdoor, right? But the influence of a state actor given 14 years to compromise a team shouldn't be dismissed out of hand.
Kaspersky AV hobbles my core i7 to the point where it can't even respond to keypresses. I have no view on its anti-virus abilities, but my every experience of it (the client and the management tools) is that it's shoddy enterprise churnware.
And, of course, they also promote it as if it's the best thing ever.
I guess the OS team could be the best ever. But my starting position is "ha ha, as if".
That said, they are apparently stable enough to emulate enough of Linux that from another OS that you can simulate a Linux OS as a container and run software as if it's on Linux.[1] So, to my mind that implies that while they may not be formally specified, it's not too hard to look at what's actually implemented and treat that as a sort of loose spec.
Treat it as someone saying "I don't like pizza" when you do like pizza - it means nothing to your enjoyment of pizza.
He places functionality over security, and assumes security will just 'happen' with code quality. I tend to disagree - but I am typing this from a Linux box, not an OpenBSD box. Because Linux is more functional as a desktop - the irony there isn't lost on me.
Or, improved BSD, and avoided all that GPL stuff if they wanted.
Let's just call it Another Missed Opportunity for the Big Blue. :)
Kylin, for others googling: https://en.wikipedia.org/wiki/Kylin_(operating_system)
It since switched to a Linux base and today powers Tianhe-1 and 2.
I was really disappointed in how Apple treated BSD, but I am stupid and naive. I would have expected that from IBM though.
Would you go into more detail here? The BSD license is very liberal. That's no excuse for bad behavior, but I'm unfamiliar with bad actions on Apple's part wrt BSD, which I gather there were given your phrasing.
However, they used to really flaunt their BSD roots on OSX, but seem to do very little to give back in the form of code, money, or even PR for that matter.
Here's an example of that: https://developer.apple.com/library/content/documentation/Da...
But now they've even removed any mention of this, and allowed projects like OpenDarwin and such to just plain die. I think it's pretty poor behavior from a company that's SO involved in intellectual property rights to just take something as valuable as a complete kernel and userland (not GUI) and then just sweep it under the carpet because no laws require them to do otherwise.
Puts a really bad taste in my mouth to see such important work treated like that. I'd have expected it from IBM, but not from Apple.
I don't know enough about the levels of contribution to either to make a strong comparison, and I'm more than willing to grant IBM and Red Hat make much larger contributions to Linux than Apple does to FreeBSD. And I sympathize with the desire to have more contributions. The "how Apple treated BSD" phrasing sounds like there is more active bad treatment rather than not contributing enough. Maybe the hiring of Jordan Hubbard is considered active bad treatment? (Honest question)
[0]: https://opensource.apple.com
[1]: https://wiki.freebsd.org/Myths#FreeBSD_is_Just_OS_X_Without_...
That's Clang/LLVM compiler that gets them off GCC's GPL codebase. It also allows them to keep more extensions proprietary if they choose. It's been beneficial to the OSS community but I'd say it's barely altruistic. An exception rather than the rule.
" The "how Apple treated BSD" phrasing sounds like there is more active bad treatment rather than not contributing enough"
Helps to remember that it's how a lack of contributions is commonly phrased. Freeloading is probably the dominant model for both users and companies far as FOSS. It's just how they word the gripe. I agree they should probably use clearer phrasing for others not deep into this subject matter.
There is Wayland which aims to solve these security aspects mentioned in the blog post, it will be shipping by default in the next Fedora release IIRC.
This could either mean that Windows 10 has become more secure than its most popular competitors, or that researchers hadn't invested enough resources to audit Windows 10 properly.
Taking into account the results from previous years and previous versions (like 8.1), my personal conclusion is that Windows has actually become more secure.
[1] https://www.cvedetails.com/top-50-products.php?year=2016
The stark contrast is in the privilege escalation vulnerabilities from the Windows side vs the other categories on the Linux side.
I would assume that many persons prefer a server to go down, corrupt its data and leak it, rather than get compromised. The fine print is that the leaked data may contain information to compromise the server[1].
OSX is right behind it, with a culture of laxness that undoes most of the benefits the designers tried to give them.
Not quite as bad, but still pretty weak.
the security problems with linux I wouldn't want to dismiss though. I evangelize FOSS since the mid 90ies and we had a good laugh for 20 years whenever Windows messed up (remember trustworthycomputing.com ??). It is hard to dismiss that being accused for 25+ years for insecurity has nothing but boosted their situation. Whatever the perceived quality of Linux, security is currently not it's strongest feat.
Systems should become more resilient under pressure over time. But in the case of Linux the problem was lack of external pressure and increasing arrogance and dismissing many of it's shortcomings. People still are way too touchy whenever somebody picks on Linux. The 0day window of vulnerability is a pretty good indicator over how it compares. Thegrugq's comparison of OS security (slightly NSFW) https://grugq.github.io/presentations/COMSEC%20beyond%20encr...
Source: ex-employee.
They mention signatures, and it kind of sounds as if the OS will refuse to execute any non-signed code. Again, sounds like a good idea in principle, but remember how Stuxnet came with - IIRC - two valid signatures created with stolen keys. It might be better than nothing, but to an attacker with sufficiently deep pockets, no quantum computers are needed.
Of course, those are just random thoughts popping into my head. I should wait for more details before passing judgment. A (verifiably?) secure OS for embedded and "IoT" devices would be very desirable, that much is certain.
The more terrifying crypto demo, IMO, was the Flame rootkit, which used a new MD5 collision to forge its signature bona fides.
Of course, iOS has AMFI which is supposed to enforce code signing, but it doesn't always work...
> OKL4 shipments exceeded 1.5 billion in early 2012, mostly on Qualcomm wireless modem chips. Other deployments include automotive infotainment systems.
> Apple mobile application processors beginning with the A7 contain a Secure Enclave coprocessor running an L4 operating system. This implies that L4 is now shipping on all iOS devices, the total shipment of which is estimated at 310 million for the year 2015.
Also, OKL4, specially the version claimed to run on qualcomm is very different from the original L4 (I say claimed since multiple attempts to reverse engineer qualcomm baseband firmware showed no traces of OKL4)
edit: if you think this is incorrect please provide a valid counterpoint. downvoting a post this way to hide its presence is not a valid response.
iOS is quite popular, but embedded ≠ “runs on ARM”.
It's popularity was just relative, though. In mobile phones, one microkernel was more popular than others. vxWorks and QNX were more popular in embedded space in general than L4's. I don't know the exact distribution.
Okay, if I look more closely, OKL4 seems to be used as a hypervisor to host regular kernels. I am not sure how much that buys one, really, from a security point of view.
Also, the same Wikipedia article states: "Apple mobile application processors beginning with the A7 contain a Secure Enclave coprocessor running an L4 operating system. This implies that L4 is now shipping on all iOS devices, the total shipment of which is estimated at 310 million for the year 2015."
[0] http://news.yale.edu/2016/11/14/certikos-breakthrough-toward...
[1] https://www.usenix.org/conference/osdi16/technical-sessions/...
At the component level, Linux also empowers the chip vendors to build what they want on their own timescales and then address a large market. Even open Linux drivers are sometimes loaders for proprietary firmware, so they aren't really giving up the ability to ship code in a black box.
I don't see any of them willingly cooperating with a company that wants to manage and deliver the whole OS from the the kernel up. TLDR: The industry probably does not want a Microsoft for IoT.
Kaspy OS runs on a switch, and they're talking about popular operating systems, so in the same vein, OpenBSD wouldn't be a popular secure OS for e.g. routers?
But hey, I'd be really happy if they based it on seL4 and formally verified their security concepts. That would be a real game-changer. OTOH I'm really sceptical until they provide any relevant details.
To make a verifiably secure system for network infrastructure and IoT-devices, you need, at the very least, a provably correct IP stack. Want a nice web interface? Now you need to verify the HTTP server, too. Want to talk to other devices? You probably want a DNS resolver. And so forth...
Simply signing code and having the OS refuse to execute code without valid signatures is not going to be sufficient to convince a lot of people that it's a significant improvement security-wise.
(If, on the other hand, they make it open source and provide proofs of correctness for all these components, that would indeed be a significant step forward.)
But my point was that it still leaves a whole lot of attack surface. If you want a provably secure system, you basically need to verify much more than "just" the kernel.
On the upside, if one did so, it would have benefits beyond security.
http://www.lynx.com/lcs-lynx-certifiable-protocol-stack/
The minimum I've seen are a few drivers, bootloader, partitioning filesystem/storage, partitioning networking, and language runtime (esp Ada or today Rust). That's not a lot to build given what's already available in FOSS or embedded. More than just a separation kernel but not much more.
This will be a russian OS, designed to allow russian companies to buy routers, switches, and firewalls that are not made by western companies.
It has to scare the shit out of russia to think that if they did have a war with the west, they would lose their access to the technology needed to run their businesses. This is a first step towards trying to build some type of technological independence from the west.
And they have good reason to be. The US has really shot itself in the foot by intentionally compromising the systems we create. Hopefully we can use this (and similar actions by other countries) to turn that around.
Open-source hardware would be great at counteracting this (and for other reasons), but it's harder than open-source software.
This is actually the crux and to my knowledge is non-existent.
https://lwn.net/Articles/688751/
Some folks trying to do open hardware:
And this is not step forward, but to the side, since they're becoming technically dependent on Chinese now.
Outside of national politics, Russia is most likely to steal the I.P. of say an American user outside of it. Whereas American intelligence and police organizations might lock up that same user for some bullshit. Situation is reversed for a Russian considering U.S. solutions. Some countries or organizations are unlikely to steal your I.P. or attack you. They become better choice than the aggressive ones. Then there's multinational, FOSS projects with strong security focus at the high-end. Gotta build them from carefully-acquired source, though. ;)
Kaspersky Lab: Based In Russia, Doing Cybersecurity In The West: http://www.npr.org/sections/alltechconsidered/2015/08/10/431...
Russia’s Top Cyber Sleuth Foils US Spies, Helps Kremlin Pals: https://www.wired.com/2012/07/ff_kaspersky/
Global Cyber Security Firm Kaspersky Denies KGB Ties and Helping Russian Intelligence: https://themoscowtimes.com/articles/global-cyber-security-fi...
https://en.wikipedia.org/wiki/Eugene_Kaspersky#Alleged_affil...
PS. Perhaps I just missed some publications, so I would welcome any links.
1) there is none 2) they are too good at hiding
Even your anti-virus companies has worked with the govt to allow some govt sponsored malware through.
Would be great if Kaspersky OS will be free and open source.
I've been slightly paranoid after it was revealed that Kryptowire discovered backdoors in some Chinese made smartphones:
http://www.nytimes.com/2016/11/16/us/politics/china-phones-s...
It was not a bug. Rather, Adups intentionally designed the software to help a Chinese phone manufacturer monitor user behavior, according to a document that Adups provided to explain the problem to BLU executives
And extra slow, considering Elbrus performance.
Linux cannot do anything about it.
I get not everything on the system is pure FOSS. But every binary ball isn't NSA spyware. If you assume that is true, you literally cannot use ANY computer.
FOSS OS's make it nothing but a question of work-hours to do the full trust but verify paradigm.
You could go into that rabbit hole. I'd recommend against it... I lost days reading all the docs and playing with this
To get access to POWER8/9 literature you sign away your rights to OPEN-POWER. Also if you make anything for POWER8/9, under a public license (what license you can/can't use are dictated by the license agreement), using docs obtained from an OPEN-POWER member company if that member company upon leaving the OPEN-POWER may claim ownership of your code.
They'll really only let you use 3 Clause BSD or Apache2. Linux has the only exception for GPLv2, and GPLv3 is banned, using it on a project can have your membership to OPEN-POWER revoked, and your code ownership transferred to IBM. If they decide to purpose it.
OPEN-POWER isn't open. The docs are free and if you write anything too useful a high paying member can seize your software. The only protection from this, is to buy in as a high level enterprise member. OPEN-POWER is down right predatory for research free-tier membership.
The point is - it's about the only way to do a real actual code audit on what your processor is doing.
There's been many options but basically little individual, non-profit, or corporate work to make them happen. (shrugs)
I think it's easier to do deep packet inspection if you're that concerned, honestly.
Especially if it's intermittent or simply passive. Then you could have an embedded issue for years and never know (I've long suspected that this could eventually be a problem for Defense companies)
Mobile phones are an amazing platform to do... well, almost anything. There are some areas where their possession is restricted, though I suspect a motivated party could sneak a stripped down mobile device into nearly anywhere.
Keyboards, on the other hand. Wow. I've seen even airgapped systems have random keyboards right off the pallet slapped onto them. These sit in racks for months or years, then get tossed usually to a recycler, a donation program, stolen, or just thrown into a dumpster. Considering how much tech is in a keyboard, and how much volume it has, you could place nearly anything in there and possibly go ages without catching on.
A scenario that I recently pointed out as a 'thought exercise' was a refitted USB keyboard with a microphone, pinhole camera, and simple keylogger+screenshot engine that contained an intermittent RF/wifi/bluetooth/ultrasonic network. Programmed to dump its payload whenever an individual passed nearby and triggered it remotely.
Such a trojan could sit in a datacenter or conference room for years completely unnoticed. The data it captured transmitted only to the cleaning crew or whatever.
Worse yet, such a device could also pass instructions to the system it was attached to as an actual USB device.
You could fit a lot of horsepower in an innocuous Dell or MS or whatever mass-produced keyboard. Toss it into a top level conference room for corporate espionage, toss it into a data center for more direct trouble, whatever.
Scary thought, and I think part of why I still use the same keyboard I've had since 1997 ;)
You're thinking on the right lines. I've thought of weaponizing them, too. Main reason most don't is someone might look inside one. Even if it's not the target, finding something obvious could make the news with result that attack no longer works. That's why NSA weaponizes the USB connectors themselves. I do think there's room for doing what NSA is doing in a mobile-style SoC that replaces main MCU of the keyboard with same labeling. People would be none the wiser unless carefully measuring electrical properties.
" and I think part of why I still use the same keyboard I've had since 1997 ;)"
Haha. I keep updating but I stopped trusting the computers a while back. Far as subversion, most PC-level subversions seem to have started close to 2000 with NSA's programs kicking in around 2004. So, I recommend people use pre-2004 or pre-2000 tech. Plenty of usable stuff in that category.
https://news.ycombinator.com/item?id=10468624
It's a hard problem. That's why DARPA is throwing tons of money and brains at it right now. Also why a number of defense contractors maintain their own fabs and packaging plants despite the technology aging.
End of freaking story. If you don't, and/or you can't throw a fab plant at it, your options are limited. You can read all the docs on the open CPU stuff (as far as that goes), you can literally do everything from scratch, but unless you're a Nation State or a massive company, you're pretty much wasting your time.
/edit: I don't mean this as a criticism of your writeup (where you basically state the same thing), or even some of your other comments (where you state much the same thing). It's literally an issue where there are VERY few people in the entire world capable of doing cutting edge processor design, coding, and implementation. They cost phenomenal amounts of money, and even with the money, people, and the best of intentions - a motivated nation state actor can muck things up.
The only real defense we have, as regular people, is to basically see if anything we own is misbehaving. Even that is a specialized skill set and time investment beyond what most folks are interested in committing.
Equals you trust blindly or don't trust at all. There's a whole range of verifiability between those two. It's worth exploring.
"but unless you're a Nation State or a massive company, you're pretty much wasting your time."
There's smaller firms on buying and supply side of the equation benefiting from simpler, easier-to-inspect stuff. Especially for energy or cost savings. Examples include Moore's Forth processors, Java CPU's, Plasma MIPS (FOSS), 16-bitters in smartcards, etc. Those on 0.35 micron or up can have random samples inspected by eye with microscopes if user wants to go extra mile. Alternatively, they at least have black boxes they can analyze or test for conformance to white-box designs they're supposed to be. Or more easily monitor at analog or digital levels for inconsistencies w/ power shut off during such an event.
Much more to this topic than you're suggesting.
I'm happy to hear that there are some smaller fabs and things that are easier to inspect, but I think that the commodity level of most hardware still makes it super unlikely.
If a company is willing to use Office 365 (which I can neither confirm nor deny some very large shops might use, but wouldn't be out of the usual), you cannot seriously expect them to pay proper attention to what their processors are doing.
I would hope that if someone worked in high-clearance, there would be MANY such measures in place. The ease with which a fully loaded laptop can walk out of Los Alamos wouldn't really lend credence to them patching the biggest hole... the people.
You are my favorite form of security guy - the insanely suspicious sort who is always looking for the weakest point. But when it comes right down to it, there's billions of weak points at much higher levels and much more easily compromised than a chipset or compiler. It's a good academic exercise though.
Oh I'm with you on this. Steve Walker's Computer Security Initiative and the Orange Book gave us lots of highly-secure stuff for defense, etc. They got rid of that for cheap, fast, fully-featured COTS. The same happens in business, aerospace, etc. The exceptions are usually pre-made appliances or, in aerospace, better components in the DO-178B Level A stuff. Much of it is shoddy. A good chunk of the defense fabs' business is probably replacing legacy parts in old equipment at prices guaranteed through corrupt contracts. They don't give a shit about security in general: just money. ;)
"But when it comes right down to it, there's billions of weak points at much higher levels and much more easily compromised than a chipset or compiler."
There's lots of weak points. Stopping code injection from all known vectors with simple, proven techniques at CPU and language levels eliminates the whole malware problem if apps are whitelisted, built from source, and include no executable scripting/JIT. There's ways to conveniently enforce POLA within a system (eg CapDesk), do secure (even automated) configurations of networks (Boeing's Survivability Grammers), and so on. There's components for most use-cases just waiting to be productized, integrated and sold to larger audience. Given this is 90+% of attacks, it's certainly worth pushing to establish a stronger baseline for companies that want less loss of secrets, availability, data, etc.
There's only so much the traditional methods like coaching and monitoring can do if one can simply open a folder (not a file!) that immediately results in full-control of machine by malware since a thumbnail rendered. Endless crap like that exploiting underlying foundation of quicksand. The HW and SW of endpoints, at least at lowest layers, need to get in check for that other stuff to be meaningful. I'm also in favor of an integrated networking stack that makes different applications, even if using TCP or HTTP, look visibly different at the packet level so NIDS spots weird patterns more easily. Like the MLS extension but not MLS policy itself. Do it at application layers with stuff like Ethos's eTypes or security-enhanced ZeroMQ where developers don't worry about plumbing much.
" It's a good academic exercise though."
It's also an industry bringing in tens of millions of dollars at least. That's with costs that are too high, lack of key software support, and little to no advertising. I imagine it could be larger than tens of millions with such obstacles reduced or eliminated.
If it could be done with proper 'design by contract', inspections, and at a cost that folks could swallow, you might have a new Apple 2 on your hands. Not in the corporate world, at least not immediately (where tomorrow's profits outweigh next-week's), but among security cautious folks and researchers.
I'd love to see if a laptop, for example, could be built to that standard. And if built, if it could actually accomplish real (not hobbyist) work. BlacktOPS or something catchy :)
You can use one, but you can expect it's exploited. It might not be a happy fact, but we shouldn't deny it if it's true.
The NSA by itself has 40,000 employees, tens of billions in budget, the best tools and tech in the world, and a track record of doing such things. I expect that if they see a valuable vulnerability, they will develop an exploit.
Answer isn't optimistic...
Priorities. :|
Even disregarding vulnerabilities, these OSes are not secured by design. Keeping your OS secured is a strong trade-off with convenience.
Although I guess that if you use OpenBSD, that's a strong signal that you want to go the extra mile in the direction of security.
I use it for my router, but my desktop is Linux (Steam. It's because of Steam. I'll be totally honest :D )
There are quite a few open source operating systems that you can personally verify that they protect your information appropriately.
That's basically what I was always telling myself in the back of my mind during the latest US election, every time I heard that the Wikileaks DNC email leaks were originating from Russia :D
I know for sure that my apple and my linux boxes aren't making any network connections that I don't understand.
It's turtles all the way down.
I'm being a little sarcastic, as obviously, they aren't watching everyone all of the time, really, and most devices' backdoors, for those that have them, are unused. I'm fine with all of it, for the most part. Yeah, I'm not perfect, and I don't want all my info made public or sold, but we give up much, much more just by everything being online. Our banks, investments, to some extent our medical history, geneology, likes/dislikes, actions, schedule... it's all there. Each of us could be simulated with all of the info they have at this point, but they can't fully- yet. Now they just have to keep and mine all the data- which they do, but it's selective; it'll be a lot less selective about what is analyzed as time goes on. Then one or more AI's will decide what will happen to all that information, and us, if we don't all kill our planet or each other before then.
Best thing to do? Use the hell out of Kaspersky OS. Use Red Flag Linux. Just take all of your banking info and give it to the Nigerian whose been asking for it. If we all just gave up on security, what would humanity do with all of that trust? Ok, maybe not such a good idea... maybe paranoia can help you be a little more secure, for now. However, if it's open source and you build it yourself- then at least you could look at it, if you wanted, and had time.
Isn't it, though? Apple seems to be the only company that has stood up to the three letter agencies. (I'm a US citizen.)
No, it's not the same. Despite its flaws, the United States government is not at all the same as Russia's.
You sure about that?
https://wikispooks.com/wiki/US/Efforts_to_Suppress_Democracy...
https://igurublog.wordpress.com/2014/04/08/julian-assange-de...
http://www.theverge.com/2013/12/20/5231006/nsa-paid-10-milli...
https://www.quora.com/Is-there-any-backdoor-left-in-Unix-or-...
https://blog.cloudflare.com/how-the-nsa-may-have-put-a-backd...
On one hand, we've been privy to some of NSA's operations, on the other, there is still a lot left to be disclosed, most will of course, never be out in the open.
That's the problem with intellectual americans - you guys know how bad things are in your country, but not realize how worse they are everywhere else.
> That's the problem with intellectual americans - you guys know how bad things are in your country, but not realize how worse they are everywhere else.
What? Just because some situations are worse in other countries means the US can't be doing anything wrong?
Are you talking about National Security Letters? That's a complex topic. I would hope the companies did what they could to fight where they had room, but I also don't necessarily expect companies to break the law.
If you're talking about data, the NSA tapped private datacenter connections, and I'm under the impression that Google at least was working to mitigate this (encrypt all datacenter-to-datacenter traffic) before all this came to light. Or are you referring to something else?
Indeed it is complex, but the end result is still the same. Sure, they don't have to fight the law, but I also don't have to trust them with my data. Nor does Russia, and I'd even argue that it's stupid for Russia to do so.
If they release this as open source I would be interested in looking and learning more and in a year or two, if the community develops maybe it's something worth deploying to production
But a completely new OS? Not on day one I think
Without specific details, it sounds pretty much like any random Glassdoor report from un unhappy employee.
There is a history of the company suing ex-employees and vice versa. It's pretty ruthless if you break NDA - people get real jail time. I got reminded about that during my exit interview.
I left for financial reasons. They simply refused to give raises to virtually anyone after RUR tanked in 2014, even though 85% of the company's revenues are from foreign sources.
If a business wants to survive in the long term, it should always answer this question with: Would it be better if we would build it or others would do it? Because someone will eventually do it.
Understandably, investors do want catchy stories and media buzz... :)
Looking forward to hearing more about their OS.
Did you miss HYDRA, Secure64, or the MILS/DO-178B groups building certified, partitioning middleware?
https://news.ycombinator.com/item?id=12988808
http://www.lynx.com/lcs-lynx-certifiable-protocol-stack/
It's been going on. The OEM's just aren't buying or cloning any of it outside a few. Many of those that do are going out of business because customers vote against security with their wallet. Even when the cost isn't much more. Outside of pure defense contractors, one of only ones making it is Genua selling OpenBSD-based solutions in Layer 2 and 3. Assuming they're still OpenBSD-based.
"Looking forward to hearing more about their OS."
I agree with this and your view on the need to develop more bare-bones, clean-slate solutions for these kinds of services. If we're lucky, Kaspersky's will both be more secure than Linux-based products and have convenient, affordable licensing than forerunners to get major adoption. However, as you probably know from high-assurance, a company with no history of making a system secure against strong attackers will probably fail to do so with its products. That's my default anyway. So, I also look forward to the details to compare and contrast against competing solutions in medium- and high-assurance spaces.
From a company based in Russia?
Really?
But we do have proof USA does that. See Snowden leaks.
http://arstechnica.com/tech-policy/2016/06/russias-new-spy-l...
Also, Redox is switching to a microkernel architecture...
re Redox. It's a nice project I've praised before. It's an alpha work-in-progress, changing rapidly, and unclear how much of its design is truly for security. A trimmed OpenBSD is probably a safer bet than it so far given the staggering amount of review that went into it. Rust's features and a microkernel only prevent so many kinds of problems.
- https://twitter.com/gN3mes1s/status/798992790436933632
- RU slides http://osday.ru/presentations/duhvalov/9jun.rifinnopolis16-1...
- RU presentation https://www.youtube.com/watch?v=_iEaY_CGcy8
I'm not going to say no one is attacking switches, but that's definitely not where I'd start.
Built from scratch and secure, no Linux input. It's the Holy grail, move over Theo.
Not only is this co-operation extensive, documented and widely known there has been zero action, prosecutions or accountability from Snowden's leaks so far.
Kaspersky is an antivirus vendor with insignificant users and influence. Why care about Kapsersky when wide scale surveillance and 'co-operation' with the NSA of most US companies carries on uninterrupted inspite of the Snowden leaks.
That seems far more 'dodgy' than anything Kaspersky and Russia could be up to.
Now that we have tools and methodologies for verification, the announce of yet another secure OS suddenly sounds much less impressive.
To quote, "Most proofs in this repository are conducted in the interactive proof assistant Isabelle/HOL".
They built infrastructure to build verified OS stuff faster/cheaper. For example, they reimplemented ext2fs for Linux.
"And then there are some details that will remain for certain customers’ eyes only forever, to ward off cyber-terrorist abuses."
https://eugene.kaspersky.com/2012/10/16/kl-developing-its-ow...
So any new platform would first need broad adoption, then a few years of maturity in able for the outside world to assess if it's more secure than current systems.
Obviously, security centric design helps a lot, but on the other hand Kaspersky is a relatively small player in comparison with the other OS-movements (whether capitalist or FOSS).
Yes, in the common case, the more popular the system, the more profit can be made by hacking it. But if a system is running on a few, but very strategic places, it will be an interesting target and thus attract a lot of effort.
We've all learned that it can't be relied upon as a sole defence.
Interesting to see if this catches on in the embedded / IoT space, I guess it's a bit of a leap writing drivers / software for a different OS
So me too I have a dream. In my dream, every shop that needs two threads running and one semaphore synchronizing, will cease porting Linux and instead will roll up the sleeves, writes their own kernel 100% matching their need, prove its validity via formal verification and then use it.
In the world where this is possible, why would one go for a non-generic OS from a third party? Does look to me like Kaspersky might have that same vision for the future and tries to leverage their assets while it is not too late.
But security-by-brand-name is not really better than security-by-verification, isn't it?
It's hard enough for one organisation to do this, given the fairly specialised set of skills it requires. Let alone every IoT vendor. There's no reason to massively replicate this kind of work. People would be better off building an ecosystem around sel4.
First, it depends on each specification -- what if the hardware is much-much smaller (IoT) and task to perform is well defined? It is hard today primarily because the required skill set becomes less and less current, but it is all demand-driven, it was not so some time ago.
Secondly, it could be replicated to some extent only -- for example, verified libraries for each device could come from each HW IP provider, instead of coming from the SoC vendor who integrated them. Say, Synopsis would provide a verified lib for the GbE controller -- to use with all SoCs that integrate it, etc. And the final integrator would take care of verifying the final integration, including his very small, fast, low-power-consuming and maintainable and 100%-dedicated kernel.
But my main argument is that the alternative is not so good-looking either. Porting and validation of the Linux kernel is performed mostly by engineers who have not the required skillset (managerial decision to spare on hires since "we have Linux") -- this is also something that I wish wasn't replicated among product makers but is, unfortunately.
Anything IoT needs a full network stack at least, and usually a set of radio drivers for WiFi, 6lowpan, Zigbee, Bluetooth or whatever. That usually amounts to quite a lot of software, which in the case of the radio stuff is often proprietary and patent-encumbered.
Asking the hardware vendors is a dead end. You might as well ask for a pony while you're at it, you're not going to get it either.
"Verified libraries" would necessarily be written against a particular OS interface and its guarantees. I'm not even sure how this process would work in terms of formal verification; even sel4 is forced to make assumptions about hardware.
The reason why you get bad Linux ports with no source and universal default passwords is simply cost. Customers do not incorporate security into their purchasing decisions - or they wouldn't buy these things - so this is what we get.
> Anything IoT needs a full network stack at least ...
My point really is, every IoT device would need only its part of the full network stack, not all the protocols currently implemented in, say, Linux, and chances are, some device will require extremely reduced subset of the network stack, especially at the lower layers and with respect to kernel interaction.
I am not a verification expert, but verifying a very reduced subset of a well-defined specs seems at least feasible -- how would we verify something open-ended? Those pesky little theorems would become much more general and would come in even greater numbers?
Verifying a generic OS, good for all devices and all application, if at all doable from theoretical standpoint, looks too much of work for no particular profit for the verifier (very similar to the validation of the Linux kernel which is relayed on to the distro builders).
I wouldn't be as pessimistic either about the hardware vendors. After all, (some of them) already use formal verification in (some of) the silicon design, and verifying closer to the silicon seems simpler -- the closer to the metal the less genericity (assuming the verified silicon underneath).
P.S. Security without open-sourcing is impossible. Although, dunno how for other countries, but here in Russia some people have a different point of view.
Some people believe that “opensource is insecure by design, because everyone can see the code”. Probably Kaspersky has the same point.
is just as documented an assertion as
> opensource is insecure by design
The two are completely orthogonal.
I really disagree.