OSDev.org

no92 wrote:All CPUs known to me are happy with executing something that actually is data. As that's something we can't achive here on the OSDev forums using protected/long mode,

Long mode often supports NX, and by extention, W^X, Protected mode is even more thorough and allows you to strictly separate the code and data section into non-overlapping spaces - essentially making it an harvard architecture from the app's perspective.

It's still possible to bypass OpenBSD's W^X or Windows DEP. These are good methods for adding more security, but they don't offer complete security. IIRC, you can use return-to-libc to bypass it.

no92 wrote:The solution to most problems would be if the processor itself would distinguish between code and data. All CPUs known to me are happy with executing something that actually is data. As that's something we can't achive here on the OSDev forums using protected/long mode,

This is what the NX feature of long mode supports doesn't it?

no92 wrote:so we have to eliminate the other causes; namely careless programming languages (by adding features like bounds checking) and programmers of non-kernel software doing silly/stupid/flawed designs and techniques.

Are we talking security from a buggy program or security from a malicious attack/app?

If it's a buggy program then a stray pointer, stack over flow or bad return isn't likely to do much damage on it's own, just cause the app to crash. If it's a malicious attack then having the app jailed would mean a deliberate use of a vunerability would still only give you access to a locked down machine. I see this as extending the virtual (protected mode) machine we in see memory all the way down to the filesystem and hardware. It's as if each app is the only installed software on a dedicated machine.

Scaling it right up I would compare this to having a honeypot server where you let a hacker abuse this server as it doesn't affect the real system.

no92 wrote:It's still possible to bypass OpenBSD's W^X or Windows DEP. These are good methods for adding more security, but they don't offer complete security. IIRC, you can use return-to-libc to bypass it.

In combination with several other security mechanisms, OpenBSD uses position independent executables (PIE) by default on several platforms now.

W^X is a default policy enforced throughout the system, but it is certainly possible to use mmap(2) directly to shoot yourself in the foot.

Fundamentally, page protection on modern processors works. If you are developing a new OS, use it from the start!

There are two types of security: protection of processes from each other, and mitigation when a process has a vulnerability. Its useful to think about both these kinds.

After so many years you'd think that things were about as far as they could get on the security front, but recent attention on practical security has really brought real results on the software level.

For example, very low overhead compiler protections you can now enable e.g. CPI.

For mainstream processors people will really like this set of slides (yes, OpenBSD have weaponized Comic Sans!)


There are processors and future planned processors (I'm on team Mill) that bring hardware security enhancements too.

The Mill has per-byte protection granularity, has a hardware-managed call stack, has syscall-like peer-to-peer rather than bounce-via-kernel calling, bounded pointers, etc etc.

Unfortunately, it is easy to forget that the number one vulnerability is not in the software, but in the person using it. Even with malware attacks, the majority of the entry paths involve social engineering, not software vulnerability exploitation. Anyone can fall victim to a sufficiently clever, persistent, or violent effort to convince them to act in an insecure manner, and most of the time, your average user is not on guard against such abuses.

We can and should do everything we can to secure the system software, it is true. But security is a process, not a goal, and the majority of that process is out of the hands of the developers.

Schol-R-LEA wrote:We can and should do everything we can to secure the system software, it is true. But security is a process, not a goal, and the majority of that process is out of the hands of the developers.

Most system admins would disagree...

- Monk

Combuster wrote:Long mode often supports NX, and by extention, W^X, Protected mode is even more thorough and allows you to strictly separate the code and data section into non-overlapping spaces - essentially making it an harvard architecture from the app's perspective.

Unfortunately, most compilers assume fully overlapping code and data segments in PMode.

Unfortunately, most compilers assume fully overlapping code and data segments in PMode.

Oh, do they? Then wouldn't it be easy to point out valid cases where a data is read from a .text section or code is read from a non-.text section? Undefined behaviour is not allowed.
Hint: the assumption you refer to is DS=ES=SS, it doesn't include CS

no92 wrote:Wrapping every app into a virtual machine isn't the solution to all security problems. As Brendan recently pointed out, a lot of vulnerabilities in code are caused by flaws in the programming language.

It also depends on your definition of a security vulnerability. For example, if your web browser runs inside of a virtual machine, a website might still be able to take over the web browser - and so the web browser would have a security vulnerability, but not necessarily the virtual machine or greater operating system.

no92 wrote:It's still possible to bypass OpenBSD's W^X or Windows DEP. These are good methods for adding more security, but they don't offer complete security. IIRC, you can use return-to-libc to bypass it.

The Windows API offers a function to change the write and execute privileges of pages. Without this feature things like tracing JITs for dynamic languages that modify code while running wouldn't work, or dynamically loading a library during runtime.

The purpose of Write-Xor-Execute/Data Execution Prevention isn't to protect the OS (the programs already run in user mode and can only communicate via the system calls provided anyway) but vulnerabilities in the applications. You could argue that a 'safe' language with automatic memory management, mandatory bounds checking on all array data, and mandatory 'null' checks, etc. could make much of this irrelevant as it would then be impossible to load and execute arbitrary code from your data structures.

I'm with MessiahAndrw on this one. Write protection doesn't actually add any form of security. You can still write self-modifying code or execute data as code, it just becomes more tedius. It's a failed idea that only gets in the way of people who want to use it for practical and non-malicious purposes.

Blaming the language for security issues is a lot like saying that guns kill people. It's always a question of intent and where the gun was pointed. Personally, I dislike it when other developers impose their boxed thinking on me. Security isn't worth squat in a language. I can just use a different language to accomplish something malicious. If I want to have code in global space and jump/branch to arbitrary positions, that's my prerogitive. If I blow my foot off, that's my problem. I'm a responsible consenting adult.

SoulofDeity wrote:I'm with MessiahAndrw on this one. Write protection doesn't actually add any form of security. You can still write self-modifying code or execute data as code, it just becomes more tedius. It's a failed idea that only gets in the way of people who want to use it for practical and non-malicious purposes.

Blaming the language for security issues is a lot like saying that guns kill people. It's always a question of intent and where the gun was pointed. Personally, I dislike it when other developers impose their boxed thinking on me. Security isn't worth squat in a language. I can just use a different language to accomplish something malicious. If I want to have code in global space and jump/branch to arbitrary positions, that's my prerogitive. If I blow my foot off, that's my problem. I'm a responsible consenting adult.

How about that webpage you just visited? That game you just downloaded from your appstore? Should they be allowed to have code in global space and jump/branch to arbitrary positions, as is their prerogative? Have you given those adults your consent?

My first few computers ran off cassette tapes and most of my games were copied line-by-line from magazines and books. Back in those days a personal computer was a single-task single-user single-audited systems. And then I got a tape of a game downloaded from a BBS and ... it was just bits and I ran it. It wiped my hi scores tape. It was probably just a bug, not malicious.

willedwards wrote:How about that webpage you just visited? That game you just downloaded from your appstore? Should they be allowed to have code in global space and jump/branch to arbitrary positions, as is their prerogative? Have you given those adults your consent?

They already do. It's pretty much required for JIT compilers and virtual machines to work. I'm not affected any differently by their actions. On the other hand, suppose I was one of the developers for their software. I'd be spending much of my time trying to write cross platform wrappers and writing functios for complex memory management just to do it.

The functionality is already there. All write protection does is make it tedius to do, it doesn't make it impossible. If you wrote a really nice wrapper, you could probably make it easy (at least for a few machines). But if it's now easy, then what's the point of having write protection in the first place? Why not just disable my keyboard to prevent me from writing malicious programs. Oh, but just in case I need to send a bug report, you'll let me have an OSK...

I think we're being trolled?

The idea that exploit mitigation is not worth bothering with is ... mind-bogglingly untenable.

http://www.openbsd.org/papers/ru13-dera ... 00001.html is the presentation I usually try and convince people to go through.

Now I'm involved in chips that try and provide 'real' security to make e.g. ROP break etc. However, we're also trying to make mitigations cheaper.

Exploit mitigation is a crucial ingredient in any modern OS and HW.