Other archs took other paths. PAE also allows that not to be always the case.

SPARC you need to look at the MPU the differences in design that give the SMEP and SMAP style protection is a little long for a blog post.

‘SMEP bit make execute obey ring settings.’

No, the ring model by design allows inner rings to access memory segments belonging to outer rings. Maybe you should consult this thing called a “textbook”?

Finding blocks RWX in ring 0 on SMAP intel systems get you no where attempting to write to it from ring 3. ‘

Hmph… Did you read this, fail to comprehend it and decide instead to make up this bit of nonsense just to pretend you know something? This (garbled) sentence certainly points to this likely possibility.

Anyway, Set-AC and Clear-AC are instructions for manipulating the AC (alignment check) bit in the EFLAGS register, which is used to determine if SMAP is to be enforced or not in the yet-to-be-released Haswell processors (and for checking unaligned memory access in 486 and up). CLAC unsets the AC bit, which results the CPU not raising a page fault when kernel mode code attempts to access memory belonging to the user space. The entire mechanism has simply nothing to do with memory belonging to the kernel space and is thus incapable of dealing with the scenario described in the “RWX kernel page” section.

‘These features have existed in sparc chips over over 15 years the tech was new for Intel basically old common crud for everyone else including arm.’

Interesting. As far as I am aware, SPARC does alignment check but not anything even remotely similar to SMEP or SMAP. Maybe you would like to substantiate that a bit?

Linux 3.7 has this to go in.
SMEP and SMAP. All the flaws the guy lists for getting around SMEP. Are basically killed by SMAP.

SMEP bit make execute obey ring settings.

SMAP that prevents writing where you should not based on ring. Yes one letter difference between the two things. Finding blocks RWX in ring 0 on SMAP intel systems get you no where attempting to write to it from ring 3. You need to be ring 0 to write to them. Lot of common attacks against SMEP+NX is worthless against SMAP+SMEP+NX. Copy from user-space function will have to be used unless you go by the module loader. Big bad news under Linux copy from user-space function auto applies NX.

To change ring level access of a page you need the instructions CLAC/STAC only in ring 0.

The is the progressive problem. Each time attacks find a weakness the hardware is now altering to prevent.

And the big reason why the security lady would have got in no trouble. These features have existed in sparc chips over over 15 years the tech was new for Intel basically old common crud for everyone else including arm. x86 is late to the security party. Attackers have got use to taking on defective hardware.

That Exploit Guy attackers have had 15+ years to beat this style of protection. Fully implemented we know the results. Attack styles against kernel will be limited to return to object attacks. Tech to prevent those already exists. One problem x86 chips don’t have that yet.

‘Funny enough intel video cards recent generations have a hardware video memory manager.’

Let me guess, you looked up something like this and decided it’s somehow related to security. Well, it isn’t.

‘You put your security information into that and a sideways attack is not possible using gpu code if the permissions have been assigned.’

Look – you invented this thing called a “sideways” attack (which I mistook for a real form of attacks known as a “side-channel” attack, which takes form in such sophisticated methods as looking over someone’s shoulders for the password and putting a fake card reader on an ATM), and then somehow the only way to defeat this obscure mechanism is to either use SELinux or employ hardware acceleration features that have naught to do with operating systems security. What you give me here is not a real argument – it’s science fiction, and, in all honesty, it’s hardly an interesting read, either.

‘Really get a copy of Windows 8 and check how it does things. Windows using the keys in the UEFI KEK for things other than booting. Yes there are more than 1 certificate store.’

Apparently, you seem to have difficulty grasping the basics of digital signatures. You probably looked at Windows 8 certificate store and decided it somehow has control over the signatures database or the key enrollment key database. Well, guess what – because UEFI isn’t designed by oiaohm, it doesn’t:

“The OEM stores the signature database, revoked signatures database, and KEK signature databases on the firmware nonvolatile RAM (NV-RAM) at manufacturing time. These signature databases must be included to boot Windows by using Secure Boot.”

In other words, you can’t alter the KEK database without overwriting the NVRAM containing the UEFI firmware, and features for locking firmware from unauthorised updates have been around for about as long as NVRAM has been used for storing mainboard BIOS.

‘Joanna Rutkowska only talks about intel chips. She does not have AMD. That is important. The feature has existed on AMD chips for years.’

Sure, sure! Because a renowned security expert would certainly have not got lambasted by her peers for proposing an existing thing as a new idea at a technical conference, now would she?

‘NX did not block ring to ring attacks. Also Linux was not setting NX on loaded modules.’

That’s because it was never the purpose of NX to prevent kernel mode code from arbitrarily executing code belonging to user mode applications.

‘SMEP fairly much shuts the door of being attacked.’

No, it won’t. Just as NX was unable to stop most buffer overflow exploits, SMEP will be demostrably defeated in one way or another on different operating systems in a short amount of time. Heck, there are people already working on how to defeat it on Linux.

‘NX did see a class of attacks just die.’

No, it merely made shellcode injection more difficult, but it certainly didn’t make any “class” of attacks disappear or decrease in use.

‘That Exploit Guy Selinux has a feature called system-call auditing.’

Which works by looking at policies and credentials, which almost every exploit in circulation is designed to defeat first and foremost. Again, you are basing your argument on fantasy, not reality.

‘Seccomp filters on the other hand does include the possibility of heuristics.’

No, a seccomp filter does pretty much the same thing as SELinux in regards to syscalls with the only difference that it doesn’t give you the facility to define elaborate access policies.

On top of that, you are still mistaking tools for establishing bureaucratic secrecy as measures against malicious attacks. No, SELinux is not anti-virus software. It never was, and it never will be.

‘Those credentials are per application not per user. So user running as admin on a harded Selinux gets you program and runs it and it does something more than what a normal user should it killed. You application did not have the required credentials.’

And what difference is that supposed to make? A malicious attack is usually aimed at defeating credentials. All that a policy of establishing credentials does is squat to the attacker. Even Linux without SELinux enforces an access policy of its own (i.e. root/non-root). So what?

What Red Hat does is essentially trying to promote a use of something that it is not designed for, and you, having read their product brouchers, decide that you now suddenly have the knowledge of a security expert. No, you don’t, so stop fooling yourself.

This is way different to when NX was implemented in the Linux kernel were you could go hey we will not bother implementing this. Same effect exists on AMD and VIA hardware. So most drivers in Linux do the pass from userspace to kernel space and back one particular way. The odds are any SMEP issues with drivers is almost zero. Because the feature has been implemented by AMD and VIA for ages. Windows does not support the AMD or VIA or the Intel implementation. Most likely be windows 9 before you see SMEP.

Funny enough intel video cards recent generations have a hardware video memory manager. You put your security information into that and a sideways attack is not possible using gpu code if the permissions have been assigned. You gpu code has a memory map of what memory in the gpu is allowed to access. Missing hardware feature equals security hole.

–UEFI doesn’t share the same certificate store as that of the operating system itself. Check your facts.– Really get a copy of Windows 8 and check how it does things. Windows using the keys in the UEFI KEK for things other than booting. Yes there are more than 1 certificate store.

Joanna Rutkowska only talks about intel chips. She does not have AMD. That is important. The feature has existed on AMD chips for years.

Because the SMEP ability is not new AMD chips.
“There will always be ways to defeat such mechanisms, as in the case of SMEP and NX.”
NX did not block ring to ring attacks. Also Linux was not setting NX on loaded modules.

SMEP fairly much shuts the door of being attacked.

NX did see a class of attacks just die. Most of the weakness around NX were areas where it had not been enabled. SMEP on Linux is a different matter its coming out the box enabled everywhere it needs to be.

In fact NX bit before the loader was fixed saw more most attacks against the Linux kernel move to the loaded drivers where NX was not enabled. Because many attacks just would not work.

The true fact of the matter this is no such thing as defeat theses hardware changes and keep on doing the same classes of attacks.

So ring 3 to ring 0 using attacks using executable code are basically dead in the future. So getting into ring 0 and running what ever code you want will be data struct based privilege exploits or tricking user.

The problem is SMEP and NX come into one piece. Linux markers everything bar kernel module at runtime coming from user-space as NX. Executable code inserts into the Linux kernel have been depending on the fact that usermode executable bit and kernel mode executable bit are the same.

AMD processes the NX bit is different between rings automatically under Linux. If memory was created in a different ring its automatically NX to other rings. AMD implemented the NX bit slightly differently. Result the chip is not exploitable the same way.

That Exploit Guy Selinux has a feature called system-call auditing. That dumps every arguement of a syscall. Selinux also has the means to check ever argument. Of course you don’t most of the time because its a performance over head. You are reading redhat documentation not implement is self. Redhat talks about how SeLinux generally operates and then they go in production and use it a slightly different way.

That Exploit Guy
–It can check for “certain” arguments, and I am quoting from one of those Red Hat brouchers that you treat as if they were the word of God.–
I don’t treat those at the word of God. Because they do in fact lead you away from what Redhat really does.
–It doesn’t not discern by heuristics, but credentials.–
This is correct neither does first generation anti-virus. Seccomp filters on the other hand does include the possibility of heuristics.

Linux is progressively hardening.

That Exploit Guy a lot of what I am talking about in Linux like cgroups has been off by default. Its only recently changed to on by default in a lot of distributions.

Lot of the attack vectors are disappearing. The attacks are mostly being achieved because the security is turned off.

That Exploit Guy history when it comes security does not mean it will keep on repeating. Lot of attack methods are about to end forever.

That Exploit Guy a stock Linux kernel is no where near as predictable as you make out.

–As long as you have the right credentials, everything you do is legal to SELinux.–
Those credentials are per application not per user. So user running as admin on a harded Selinux gets you program and runs it and it does something more than what a normal user should it killed. You application did not have the required credentials.

Security permissions need to be per Application and per user not just per user. Cgroups using systemd in userspace are align up for per application permissions on everything. So the Linux DAC will have applications and user permissions that the mandroary access controls on Linux have provided for years.

This is a design flaw that makes attacking windows simpler.

@oiaohm

‘That Exploit Guy reality is a scary one. AMD processors for the past 6 years have had a better memory manager for preventing security bugs.’

Now it seems clear to me you don’t even understand what I mean by “memory manager”.

A “memory manager” is a portion of the video card driver that governs the use of video memory, i.e. it enforces segmentation. In other words, it’s a software thing.

As I said, maybe you would like to read up on the subject before careening off into such irrelevant (and factually deficient) tangents?

‘The that is only one part of UEFI secure boot framework. Second is a store of keys.’

UEFI doesn’t share the same certificate store as that of the operating system itself. Check your facts.

‘The kernel faults you are worried about will die out for Linux over the next few hardware generations.’

Glad that you cited the grsec forums. Did Brad Spengler tell anything you about “Chadder Bay”?

‘The kernel faults you are worried about will die out for Linux over the next few hardware generations.’

No, SMAP will merely make exploiting vulnerability more complex. There will always be ways to defeat such mechanisms, as in the case of SMEP and NX. Also, why not ask Joanna Rutkowska what she thinks about that (provided that she doesn’t mind reading barely comprehensible gibberish)?

‘Bugger for Windows users. Same problem its windows again as why windows don’t have PAE supporting 64G of ram on a 32 bit system because Microsoft was unable to get third parties to update drivers.’

That’s interesting. On one hand, you think targeting stock kernels require time-travelling ability. On the other hand, you think targeting device drivers not compiled with the additional features are easy to encounter.

There is simply no end to your wild imaginations, is it?

‘With hardware assistance that is coming getting into kernel space is even harder.’

I would rather see you copying and pasting someone else’s blog entry and pretend it’s yours than read through a moonspeak version of it translated by you.

You see what I am getting at here?

‘In fact to idiot who don’t understand the LSM framework don’t notice that it is possible for the LSM if it wishes to notice. Because it can check the arguments of syscalls not just the name of the syscall used.’

It can check for “certain” arguments, and I am quoting from one of those Red Hat brouchers that you treat as if they were the word of God. Any argument not directly related to credentials are simply outside the scope of SELinux.

Again, check your facts.

‘This is why Selinux is very much like an anti-virus.’

Again, you have completely misunderstood the purpose of SELinux. SELinux follows policies, not patterns. It doesn’t not discern by heuristics, but credentials. As long as you have the right credentials, everything you do is legal to SELinux.

Stop trying to promote something you don’t understand.

‘Do those directories have to be real. cgroups can fake both. Selinux accessing a device or a proc file/folder you should not be is termination.’

Again, you are arguing against the possibility of something that has been achieved many times before. Why not go and do a bit of research before mindlessly throwing empty words at me?

‘That Exploit Guy there is a policy at play active use-able exploit code you do not hand around. Particularly when its cross platform.’

Mind if I ask you whose policy it is and why you are bound by it?

I think I have got a good grasp already as to what you are and aren’t, but I am nevertheless curious to see how deep a hole you are willing to dig yourself into.

‘Like if you capture screen and find out what anti-virus you are facing off against. Now you can use exploits the anti-virus don’t know.’

Hang on – what exactly is your scenario again? Or am I suppose to fill in the blanks here somewhat?

There are a lot of issues in the memory managers include the ones connected to the GPU’s.

Its one thing to go after bug free code. Its another to be sitting on top of hardware where the bugs simple cannot work. To get code into kernel space as executable will require 1 of the following.

1) Load a driver. Linux systems support secure boot these will have to be signed.
2) Kexec. Linux systems supporting secure boot this this will also have to be signed.
3) find weakness in one of the memory managers to get to where you should not.

Hardware is not going to allow any other option. There have been many kernel attacks against Linux that in x86 hardware only work on Intel chips don’t work on Amd x86 chips. Yes this is another thing that brings attackers undone attacking Linux. Its a x86-64 bit machine there is a point I can send to userspace to run some executable code in kernel space if that machine happens to be an AMD for the past 5 years that fails.

Reality is the Linux is not as easy to attack because the security features of the different CPU chips have been implemented.

–You are targeting a fixed set of vulnerabilities on popular architectures (e.g. x86, x86_64), so what exactly is the difficulty in finding out if they exist on a machine that runs a stock kernel from the repository?–

Popular architectures are far more segmented on Linux. x86_64 kernel image runs differently on a intel chip or via or amd. This goes down to security handling.

CVE and others don’t documented if security flaws are Intel, AMD or VIA only on Linux. Or even if they are only particular generations of CPU’s.

That Exploit Guy Windows is way too easy.