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

Kaspersky OS

eugene.kaspersky.com

Post reply on HN
Print view View original

251–260 of 290 posts

Re: Kaspersky OS

#251

Post by SpaceRaccoon »

hackuser wrote: post #182
kleigenfreude wrote: post #96

Earlier quoted context omitted.

Although I thought the same when I saw it, I think that's unfair. You could just as easily say Symantec/Norton/Microsoft Defender/Windows/Google is CIA/NSA. Since everything's being watched, Kaspersky might be just as much FSB as it is NSA, or any other country that could get its mitts on it. Cisco was definitely completely NSA there for a while, because of the backdoor. China's got Lenovo and every smart appliance,…

> Kaspersky might be just as much FSB as it is NSA, or any other country that could get its mitts on it No, it's not the same. Despite its flaws, the United States government is not at all the same as Russia's.

It's spying powers are only much more capable, and its information war powers equally so, which is why you defend it.

Re: Kaspersky OS

#252

Post by nickpsecurity »

this-dang-guy wrote: post #247
nickpsecurity wrote: post #239

Earlier quoted context omitted.

You can pay a company to fab a Leon3 or Leon4 for you. Leon3 is GPL with eASIC already supporting it in their Nextreme's. There's also Rocket RISC-V core that was fabbed on a 45nm SOI process. Do it on the same node with anything extra an external, swappable component on the PCB for supplier diversity. Additionally, Cambridge has FreeBSD running on a capability-secure version of 64-bit MIPS on FPGA's. It's called CHE…

Unlikely to be much unless there's a prevailing need. I think it's easier to do deep packet inspection if you're that concerned, honestly.

Deep-packet inspection doesn't help if they leak along RF or covert channels in legit traffic. Catching RF leaks outside the most common spectrum is also something requiring expensive equipment and talent. The RF methods are in the TAO catalog as pre-built tools.

Re: Kaspersky OS

#253

Post by wongarsu »

linkregister wrote: post #155
rthomas6 wrote: post #134

Earlier quoted context omitted.

But OSX, Windows, and full-blown Linux aren't used as embedded OSes either. Linux is a bit, but there are a lot of other choices.

I'm not sure if it shares APIs with Win32, but Windows CE runs almost half of every ATM I've ever used.

The other half seems to be powered by Windows XP.

Re: Kaspersky OS

#254

Post by nickpsecurity »

this-dang-guy wrote: post #248
nickpsecurity wrote: post #237

Earlier quoted context omitted.

Ahem what? That proves nothing. Here's a write-up I did on verifying hardware against subversion. 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.

And your point is? It's not a hard problem. You either trust your fabricator and tools, or you don't . 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. /e…

"you either trust your fabricator and tools, or you don't."

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.

Re: Kaspersky OS

#255

Post by wongarsu »

nickpsecurity wrote: post #174
vbezhenar wrote: post #63

Earlier quoted context omitted.

Yet it's not widely used as embedded OS. I never saw any router with OpenBSD or web camera. 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.

This defense contractor builds their stuff on OpenBSD: 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 pre…

I it's more likely that Kaspersky lumped OpenBSD and Linux together as Unix-likes (very valid since they are talking about basic OS architecture choices in that section), and chose to say Linux instead of Unix-like because Linux is much more widely known.

Re: Kaspersky OS

#256

Post by this-dang-guy »

nickpsecurity wrote: post #252
this-dang-guy wrote: post #247

Earlier quoted context omitted.

Unlikely to be much unless there's a prevailing need. I think it's easier to do deep packet inspection if you're that concerned, honestly.

Deep-packet inspection doesn't help if they leak along RF or covert channels in legit traffic. Catching RF leaks outside the most common spectrum is also something requiring expensive equipment and talent. The RF methods are in the TAO catalog as pre-built tools.

Yes - if we're going to include ultra-sonics, air-gap spanning networks, things of that nature... yeah, it gets very quickly into the range of nearly impossible to catch.

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)

Re: Kaspersky OS

#257

Post by jodrellblank »

btown wrote: post #170
mmalone wrote: post #160

Earlier quoted context omitted.

The article is light on details, but based on the way they talked about it ("impossible to hack in principle") it's likely that they actually can _prove_ that it's more secure than a Linux distro dedicated to security insofar as they're able to prove anything at all. Since the Linux APIs are not formally specified, or verified, it's essentially impossible to _prove_ anything at all (again, in a formal sense). Formal…

There's a difference between "we show you the proof, and you trust us as a service provider that the assumptions are correct" - namely that non-OSS software is loaded in the form it is shown in the proof - and "we show you the proof, and give you all information needed to audit it." Some people will buy based on only the first statement and the brand of the company. Now, we're looking at a top-notch team of OS progra…

Now, we're looking at a top-notch team of OS programmers

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".

Re: Kaspersky OS

#258

Post by nickpsecurity »

wongarsu wrote: post #255
nickpsecurity wrote: post #174

Earlier quoted context omitted.

This defense contractor builds their stuff on OpenBSD: 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 pre…

I it's more likely that Kaspersky lumped OpenBSD and Linux together as Unix-likes (very valid since they are talking about basic OS architecture choices in that section), and chose to say Linux instead of Unix-like because Linux is much more widely known.

It's possible but I'm not saying likely. OpenBSD's handling of UNIX architecture, low-level primitives, security features, and code quality stand out a lot. It's still UNIX-like enough to have UNIX weaknesses but they mitigate quite a bit.

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.

Re: Kaspersky OS

#259

Post by this-dang-guy »

nickpsecurity wrote: post #254
this-dang-guy wrote: post #248

Earlier quoted context omitted.

And your point is? It's not a hard problem. You either trust your fabricator and tools, or you don't . 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. /e…

"you either trust your fabricator and tools, or you don't." 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 o…

Even the aerospace/defense companies I work with use almost 100% off-the-shelf hardware pre-installed with OS and software by the vendors, or at least with some minimal IT work (often offshore).

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.

Re: Kaspersky OS

#260

Post by nickpsecurity »

this-dang-guy wrote: post #256
nickpsecurity wrote: post #252

Earlier quoted context omitted.

Deep-packet inspection doesn't help if they leak along RF or covert channels in legit traffic. Catching RF leaks outside the most common spectrum is also something requiring expensive equipment and talent. The RF methods are in the TAO catalog as pre-built tools.

Yes - if we're going to include ultra-sonics, air-gap spanning networks, things of that nature... yeah, it gets very quickly into the range of nearly impossible to catch. 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)

I'm for different threat profiles with different schemes targeting them. We already have regular, security researchers and black hats hitting manipulation of flash, RAM cells, sound/speakers, and I/O firmware. It has to be in the threat model at least on the software side. Unfortunately, esp given the speeds of these things, mitigation probably demands new hardware either in general (eg custom RAM) or for detection (eg verifier of RAM's expected behavior). My old scheme of diverse, triple-redundant hardware with voting algorithms just can't match performance needed of modern workstations and servers in software alone. Maybe not FPGA's either.
Post reply on HN