Posts by patrickstar

What does public clown have to do with outsourcing?

There are lots of places which even have their own physical datacenter but outsource large parts of operating the things in it.

If anything, moving to your typical public clown (like AWS) with their "lots of disposable unreliable servers" model would require a typical shop to start outsourcing, since their in-house team won't be able to deal with the huge increase in complexity that follows from that model. Plus you might actually have to toss out and replace a lot of existing, well-functioning, software.

For the "clown services" where individual servers are actually reliable, at most you've gained capacity scaling and not having to maintain the physical boxes. The latter (and to some extent the former) which you can gain in ways that don't involve using someone else's shared infrastructure with all the issues that arise from this.

In any case, this in no way saves you from needing someone (outsourced or not) to keep the things running on the servers.

Re: Crickbait

Yet when Windows boxes are compromised because of crappy admining, the Linux crowd immediately and loudly proclaims it's the fault of Microsoft...

Re: Come again?

You can presumably sniff things like EMI, or otherwise detect hand movements. Lots of possibilities here, with interesting precedent in what's been done against PIN pads.

Plus your phone has other secrets to protect than just its' contents. Like everything being said in the same room as the phone, even if it's off if it's bugged.

Regarding PIN pads, the VISA EPP standard is not meant to withstand a day or so of unsupervised access, which is what handing your phone in for repair certainly does in a lot of cases.

Or protect against a rogue service technician at all, atleast in more ways than having the keys split across multiple persons (which doesn't do you any good if the thing comes back from service trojaned to the hilt).

The scenario for DVD/BluRay/etc is to protect the actual digital data, to prevent an exact (high-definition high-quality) copy, not keep the contents per se seciret. Their whole purpose is to do a very lousy job at that so you can actually watch the movie.

Same with games - you are SUPPOSED to be able to play the game.

The scenario of a phone is to protect many different secrets from getting read out in any way, or intercepted in the first place.

Plus the value of making a copy of a single BluRay disc is substantially lower than the potential value of getting the contents, or simply bugging the environment, of a single phone.

If you hand something in for service and don't trust the service techs, consider it pwnd. This is almost a basic law of computing.

Re: And people complain about Apple discouraging third-party repair shops

And really, do people actually want unrepairable phones?

Today's smartphones can cost more than a decent desktop or even laptop computer. Do you really want them to be impossible to repair reasonably - or only repairable under the conditions and prices dictated by the manufacturer (if they're even interested in doing it at all)? Just to stop some attack scenario with dodgy parts that you'd expect in case of a nation-state level attacker and/or high-level industrial espionage, not someone out to empty random bank accounts or get ad clicks (taps?).

Just look at the uproar a number of years ago when Apple started using Pentalobe screws to discourage fiddling with the phone internals. And that's something that's trivial to defeat even on a shoe-string budget...

There could definitely be a market for phones that are essentially epoxy bricks riddled with tamper detection gizmos and severely paranoid hardware (TrustNo1, not even the screen), if there isn't already, but I doubt even the vast majority of security-conscious users would appreciate the tradeoff.

Such a phone would presumably be subject to similar security testing/certifications to other tamper-protected devices (PIN pads for card transactions, for example... or good-old fashioned locks and safes) where you have a clear threat model - an certain amount of time and/or money needed to break it. Even though there certainly is some overlap in the technology employed, this is still very different from some ad-hoc DRM scheme on random components a bunch of leet haxorz at the manufacturer came up with.

Re: Come again?

You simply need to add a small circuit board with a microphone (or other listening device - radio/EM fields/position/etc) on it. This is not stopped in any way whatsoever by any chain of trust.

Rather it's stopped by tamper protection and physical security, both of which are, by definition, not relevant if you just handed your phone to someone and expect him to switch out the screen.

There's no way to compare keeping secrets on a phone unreadable to preventing home users from pirating BluRay discs - there are simply no commonalities between the scenarios.

Regarding switching out the entire phone - sure, but it might be a tad suspicious if you hand in your old worn thing (probably dinged up from whatever broke the screen as well) and get back a brand new phone. Just sayin'.

Re: Come again?

You don't need to replace any hardware in a phone to pwn it. You might simply add a bug - this has been done since the early days of telephony.

Or you could replace the entire contents of the phone with something that just shows you a fake login screen and then errors out after entering the password/PIN code, sending it to the guy in possession of the real phone, if that's what you're after.

Etc.

Also, the threat models are radically different, but that's probably another discussion.

Re: Come again?

Again - my point is that you HAVE to consider the hardware trusted, not that someone can't actually compromise the hardware with physical access.

If someone has access to your phone to the point where they can change the screen, it's game over.

If you want to prevent that, you don't do it by putting some DRMish stuff in the screen to authenticate it (a la Apple and the fingerprint sensor). This is completely meaningless even if we assume there's no way to stick an evil screen in place considering that they have unrestricted access to literally everything.

To prevent this, you simply don't allow untrusted parties to have that sort of access to the phone in the first place.

It would be relevant if this was about connecting an external screen to a desktop computer, or perhaps some sort of Lego phone where replacing the screen does not involve taking it apart.

It's not relevant here.

This is, of course, not a new concept or fear.

In the case of a pure CPU backdoor at the mask level, it would be pretty easy to insert a backdoor that for example would allow a local attacker full kernel compromise. For example "if certain conditions are true, then bypass all page protection checks". This would be very desirable for a TLA looking to compromise phones - then all they would need would be a single clientside exploit in any app (of which there are plenty), instead of the usual chain of clientside exploit -> sandbox escape / local privilege escalation.

The same thing could be done with desktop systems of course, but somehow I imagine/hope it's more difficult to sneak a backdoor in at Intel than at some obscure SoC vendor...

Yes - good clarification.

I think the general cutoff between untrusted/trusted should be something along the lines of "if the screen is locked / user logged out, can this be reasonably be used to bypass that?"

So USB sticks would be untrusted. The motherboard would be trusted even though you could theoretically hook up a logic analyzer and signal generator to it. Memory would be trusted as long as it remains in the box (you'd expect someone to be able to remove the memory and read it out so you'd scramble the contents, but not expect it to be under attacker control as long as it remains in place).

Other considerations might apply if you have an advanced threat model, but then the answer isn't to attempt to build a box where nothing trusts anything else or even itself, but rather to prevent someone from getting in the box in the first place (tamper detection and/or filling the entire thing with epoxy and/or applying physical security like locks and safes around it).

My point is that you essentially HAVE to consider the hardware trusted. If it's compromised, game over.

If an attacker can replace basic hardware components they have already won.

Re: An Education for the TLA's

I'm sure that just about everyone for whom it would be relevant has read the Kaspersky source that leaked a number of years ago, and/or reverse engineered any parts that would be interesting.

But really, there's not much to see in standard AV software. Basically, if you sit down and try to accomplish the same thing as they do, you'll realize there are only a few ways it can be done. At most there'll be some rootkit detection tricks and such, but they will almost by definition be useless since rootkit authors will have tested their stuff against the AVs and worked around it already.

They most likely run a lot of Windows atleast, since that's what's used for pretty much all industrial control systems.

Re: And is there an actual definition of hate speech attached to this bill?

So, saying that it's your opinion that something didn't happen doesn't count as having an opinion about it if the subject is controversial enough. Got it.

Re: And is there an actual definition of hate speech attached to this bill?

In Germany, even questioning the established narrative of certain historical events (most famously the Holocaust) is illegal. People literally go to jail for years for this.

Restricting speech because the speaker has the wrong opinion on something clearly goes way beyond restricting direct incitements to violence or such.

Re: WMI (and seriously - passwords in memory?)

PS. How can someone downvote a post containing nothing but statements of fact? If any of the facts are wrong I recommend that you post a reply explaining so instead, for the benefit of all.

Re: WMI (and seriously - passwords in memory?)

Atleast MIT and Heimdal kerberos store the credentials in a file in /tmp...

In Windows, they are stored in the LSASS process. I don't know where you think they are stored or how accessible they are, but at the very least you need an administrative account with SeDebugPrivilege.

I don't have Kerberos on any of my Solaris boxes, but even if they are actually stored in kernel memory in the native Solaris implementation as opposed to a userspace process or file, none of these systems have a great track record of keeping attackers out of the kernel, especially when they have administrative privileges. And certainly none of them have a great track record of keeping attackers from gaining that.

That's why you have the whole Credential Guard thing - so that even if the kernel is compromised you can't read them out without also compromising the minimal virtual system holding the creds.

There is no difference between the ability of processes to read memory space on Linux, Solaris, Windows or any of the other systems, by the way. They all use the same basic VM/memory protection model.

And you can't hash the credentials and still have them usable as a cache. The whole point of a cache is to be able to re-use them. At most you could encrypt them with a key that's harder to access than the credentials itself, which is basically what Credential Guard is doing (though a better solution would be a HSM/TPM enforcing rules for when they can be used).

Re: It would be real funny if...

Atleast in the US, there's solid legal precedent that you have no right to restitution if the government doesn't deliver police services when you need them. I'm sure the same reasoning would be applied in this case.

See, there's a difference between actors exchanging money for goods/services voluntarily, and an actor unilaterally taking money by force with a vague promise of delivering.

Re: WMI (and seriously - passwords in memory?)

It's cached credentials, not the password store itself.

They have to be readable by definition - otherwise they couldn't be used to authenticate... That's why you have the whole Credential Guard thingie to prevent reading them out even if you compromise the normal OS.

Kerberos on *ix has the same problem, by the way.

Re: Bring Back

While having a more mixed environment certaionly can help somewhat with security - especially against automated / non-targeted attacks like this - essentially all OSes have been (and continue to be) compromised regularly.

Back in the days of UNIX diversity it wouldn't even stop a script kiddie without any custom exploit development skills - see for example http://insecure.org/sploits.html as to what sort of resources were publicly available.

Re: This might be the year MS became relevant

For your information, your default Linux installation is a lot weaker when it comes to exploit mitigation than a Windows 7 box with EMET...

Re: Linus exhibits all the qualities of pure sociopath

Uhm, Linux becoming the go-to x86 *nix clone was basically just a historical accident.

If it hadn't gained traction when it had, the BSDs would probably be where it is today.

Or maybe GNU HURD would have taken off.

Or some now-dead system would now be dominant. Or some now-nonexistent one would have been born.

Re: Grumble

The proper comparision would be whether the STAFF of IBM, Intel, et al. are working for free or not...

Not even the people involved in the KSPP are working for free. How come the grsec people (spender, pipacs and whoever else is involved) are expected to work for free, while the KSPP guys aren't?

Why is there even a KSPP when they could have just funded grsec with much better results?

Answer: Linus doesn't give a fuck about security or see exploit mitigation and hardening as something that belongs in the kernel. He along with certain others have successfully alienated the people who are actually have a damn solid track record of providing it.

Now when the pressure is on to actually do something about the sorry state of Linux kernel security, trying to mend things would mean he publicly admitting he was wrong ... which he's far too proud to do.

Besides, he doesn't actually care about security, only about appearing to do something about it, so the results don't really matter.

Enter the KSPP which consisted mostly of taking random parts from grsec without any deeper understanding of the issues. Considering that the people involved have a near-zero record of meaningful innovation in this field, I would suspect they are pretty much screwed now without public grsec patches. At most they can add a bunch of half-assed useless "features" for show, probably introducing more vulnerabilities in the process just as they have done before.

So, to save Linus' face, money is being spent on make-believe work and every Linux users security suffers.

Re: Ego Overload

The story is basically this:

Linus, and the other kernel maintainers, have been essentially ignoring security for years. Attempts to introduce security hardening into mainline has been met with indifference or outright hostility. In the rare occasion where something has ended up landing, it has been in a watered-down form with limited value, often demonstrating the commiter's lack of deeper understanding of the issues involved.

Linus has even publicly stated that he doesn't view security bugs as any different from any others, with predictable results. Lots of security issues that actually do get fixed do so more or less silently with a non-descriptive commit, causing much joy for blackhats reading the changelogs and much pain for people trying to backport security fixes to old kernels.

m

During this whole period, grsec has basically been the only way to let untrusted code run on a Linux box without guaranteeing eventual compromise.

At some point, there was some sort of debacle with Wind River marketing (I'm weak on the details here - someone can fill in perhaps?) that pissed off spender to the point where he stopped making stable grsec patches public.

After a round of bad press, the mainline kernel guys launched the Kernel Self-Protection Project with major corporate backing. It turned out to consist of poor reimplementations (or even cut and paste without understanding the details) of features from grsec/PaX. The very same features that were previously rejected by Linus et al. for political/personal/religious reasons (or plain lack of understanding) mind you, and which were developed without anything comparable to the corporate backing of the mainline Linux kernel.

Absolutely no interest has been demonstrated in actually involving grsec in any of this, despite them having been doing this work with excellent results for many years on a shoe-string budget.

Not too surprisingly, this was the last straw and now no grsec patches are publicly available anymore.

And if you think spender/pipacs produce garbage, I'd suggest you start by turning off ASLR and DEP on all your systems. They invented those, after all... grsec/PaX had those literally years before any mainline Linux kernel eventually implemented them in half-assed watered-down ways.

SELinux has stopped how many kernel exploits exactly? Of which there has been A LOT, regularly supplied with SELinux disabling shellcode and all...

And in case you thought grsec was just about exploit mitigation, it does come with RBAC as well - a very powerful ACL system.

Re: Finally and explaination

You can load microcode after boot as well, from your favorite OS. Linux has a tool for it that runs on boot - t Think it's included with Debian but the actual microcode isn't since it's a non-free binary blob.

Windows has it as well and with some luck microcode updates arrive via Windows Update.

Doing it at the BIOS/UEFI level is mostly needed when a bug/missing feature prevents the system from booting at all.

Re: ugh

Well, on the other hand, how many people actually bother (or are able) to root-cause random crashes to the Point where the microcode can be properly blamed?

Even if it's a perfectly repeatable crash most people would blame it on application/OS bugs and work around it.

I'd think that the only people who actually HAVE to hunt down bugs like this would be compiler authors and related fields.

Re: Will

I have read tons of MS source code and never seen a single GPLed source file in any of the closed source stuff...

The standard MS style also happens to be different enough from most *ix code that it'd be easy to spot if it was just a cut&paste job with license removed.

Re: So how'd they get it?

This sounds like the stuff they hand out to partners/important developers. So it probably came from one of those, not the internal MS network.

Re: ticking time bomb... tick tick tick tick BOOM!

In a real life social engineering attack you would of course have the user run some application that does it, not instruct the user to run the actual commands. That's obviously the case for Windows as well - instead of manually adding a service to the registry and starting it you'd just hand him/her/it an application that does it.

Re: ticking time bomb... tick tick tick tick BOOM!

This is not a vulnerability.

And if you can get someone to LOAD A DRIVER, that person is pretty darn owned regardless of the OS.

For your information, your shiny little Linux box (or whatever) gets just as pwned if you get someone to do 'insmod evil.ko' as root.

As you don't seem to be advocating for something like iOS where the user is considered hostile, I really fail to see what point you are making.

Hell, since you consider a PatchGuard bypass a vulnerability, you should consider other OSes (most of them) that lack any sort of PatchGuard equivalent really, really, vulnerable.