Security Versus Programming Language

[Vanadium 50]

You cannot build a castle, or a tower of babel, on a foundation of sand.

You can, however, build one on a swamp:

 

[Svein]

Security comes from the hardware.

Well, no. The hardware (with a few exceptions) does what it is designed to do. Of course you can use it wrongly ("it is not the gun that kills, but the man using it").

An anecdote: When people started using the Ethernet to transport IP packets, they needed a way to map IP addresses (with their own rules and peculiarities) to Ethernet addresses (with their rules etc.). To handle this, a protocol was devised, the Address Resolution Protocol (ARP). In short, when you wanted the Ethernet address matching a given IP address, you sent an Ethernet broadcast asking "Who has got this IP address?" and you would (hopefully) get an answer - also using the Ethernet broadcast.

But then - in the name of efficiency - somebody thought of caching those mappings for a while (in case you needed it again soon). Well and useful.

Next optimization was when somebody thought it useful to cache all ARP answers (even if you had not used ARP recently) in case you would need that address mapping. And the address mapping everybody needed was the Ethernet address of the router to the outside world. So - if somebody got access to the network, they could use ARP to get the Ethernet address of the router, store it, and then send out an ARP reply mapping the IP address of the router to themselves. Thus every packet to the outside would pass through this rogue machine...

 

[Rive]

Security comes from the hardware.

That's like one leg of a three legged stool claiming all the glory of being THE support for itself. Just - no.
There are some basic requirements for the hardware but right now most hardware is able to provide that much.

Has hardware anything to do with script worms, for example?

 

[.Scott]

It couldn't (without a hack) deal with the old segment+offset addressing, so it replaced "segment" with "selector", a 16-bit number which "uniquely identifies one of 16K possible segments in a task's virtual address space" but "the selector value does not specify the segment's location in physical memory."

C programmers hated it. C was the dominant language at the time, and C programmers really hated it. This change killed the single 20-bit address space and it killed pointer arithmetic for pointers more than 64k apart. It's hard to express the degree of hate programmers had for it if you weren't there. It was a revolt - with few exceptions, programmers simply refused to program this way, instead using just the lowest 1MB of memory where they could pretend they had an 8086.

So the customers chose convenience over security, and the vendors saw this and provided exactly that. And that lesson has not been forgotten.

I never hated that memory addressing scheme - not do I remember any coworkers ever commenting on it one way or another.
Looking back on it, it was kludgy. But it was a reasonable way for Intel to extend physical memory while maintaining backward compatibility.

Separating code and data is good programming - and good programming provides fewer opportunities for security attacks.

Hardware can certainly help, but it is not the end all. In the 1980's, Data General introduced its Eclipse MV series featuring a ring system design specifically to protect the operating system from attack - intentional or otherwise. A kernel of the OS sat in ring 0, the center, most protected ring - with its own memory. Most OS Services ran out of rings 1 and 2. At outer ring could only access services from an inner ring through a gate. I think the theory was that as long as you got those gates right, an inner ring could not be broken. Within two months of working on that machine, I discovered a "System Available Memory" management bug that would allow application code to overwrite a kernel stack segment. If I wanted to intentionally hack the kernel, I could have replace kernel stack data and return addresses to redirect the kernel to whatever I wanted.

The moral of the story is that programming bugs will always present potential attack lanes - regardless of what hardware services are available. Every time you encountered a Windows blue screen, you were looking at a potential attack lane. The program was not doing what the programmer wanted it to do.

There are hardware features that can help - both directly, as with the DG ring structure or indirectly with features that make programming less complicated (like separating code and data). There have also been hardware features that have hurt - like memory caching mechanisms or device driver firmware that could not be protected by the operating system. But when the hardware holds up its end, security rests with the software.

 

[Baluncore]

The moral of the story is that programming bugs will always present potential attack lanes - regardless of what hardware services are available.

OS bugs yes, user code bugs no.

I hand punched my first programs to run on a Burroughs 6700. At the time I was naively unaware of the security provided by the Burroughs hardware, probably because no one was hacking that system's architecture, and they still don't. Later I did discover why hardware was so important, but only after I scrapped a B6800. Coding for, and servicing DG Nova and DG Eclipse RISC processors was also enlightening. Funny how you don't know what you've got till it's gone when you find yourself programming Intel based PCs.

It is interesting to see how Intel processors have gradually developed the absolute minimum hardware support needed to implement secure systems. But those features are largely ignored by system developers, except by a very few, like the Unisys ClearPath servers that are now based on Intel processors.

Many PC programmers today lack understanding of the elegant security available from a 3 bit tag field on each word, or the concept of a cactus stack, with hardware memory management.
That goes to explain why so many users today are immersed in an ocean of insecurity.

 

[.Scott]

OS bugs yes, user code bugs no.

It depends on what "user code" you are talking about.
One of the biggest security issues was created about 7 years ago by a zero-day Adobe bug. But if you Google this, you may have trouble because there was another zero-day Adobe bug just last year.
How can the OS defend against these? The Adobe application is allowed to read and write files in the application area and connect to the internet. For many exploits, that's all that's needed.
In both cases, all the user had to do was open a pdf - which would then appear to open exactly as expected.

 

[Baluncore]

It depends on what "user code" you are talking about.

Adobe is not part of the OS, it is a user application. A secure OS should prevent an application run by one user from writing to another users files.

 

[Rive]

It is interesting to see how Intel processors have gradually developed the absolute minimum hardware support needed to implement secure systems. But those features are largely ignored by system developers, except by a very few, like the Unisys ClearPath servers that are now based on Intel processors.

I think you are somewhat lost with this. The migration of that kind of thought line to x86 is just a small corner - the main section is the boom of virtualization: and if you look for security of that level, then you have to look for the supervisor software and the continuous development of x86 based high reliability 'big' servers in general.

For any personal use OS that kind of security was never even considered - most user would just switch to something lighter with less limitations right off the bat.

You are asking for the reliability of a big railroad diesel - in a small, pink colored shopping car.

Ps.: the actual personal use OS in relation to the mainframe world would not be considered much more serious than an user shell...

 

[anorlunda]

To be secure the hardware must;
1. Differentiate between executable code and data.
2. Have hardware bounds checking on virtual memory pages used for code and for data.
3. Restrict privileged instructions to the kernel of the OS.

When you compile a C source and execute it on that system

That's contradictory because the source code is data to the compiler and the object code is data to the loader, a moment later it becomes executable code. When a OS patch is transmitted it is data, the patch file or .EXE first resides in user space, then it changes the OS executable code.

I agree with your point 1. But my definition of differentiating between executable code and data means that the executables must be changed with a soldering iron. There must be no software means to penetrate the data/code barrier. I say that because the threats I fear are all remote attacks, and because all successful malware somehow manages to get evil code executed. Remote attacks can include social engineering where the authorized user is tricked into doing some compromising act.

The title perhaps should have said secure against remote attacks. I would think is self-evident that there is no defense against a local attack that specifies, designs, replaces or destroys local hardware and software.

A secure OS should prevent an application run by one user from writing to another users files.

A web cam is hijacked remotely to become part of a botnet. Who are the multiple users in that case? Is there necessarily such as thing as a user account in a IOT device? I am trying to think of security in terms broader than just PCs, or servers.

 

[Baluncore]

That's contradictory because the source code is data to the compiler and the object code is data to the loader, a moment later it becomes executable code. When a OS patch is transmitted it is data, the patch file or .EXE first resides in user space, then it changes the OS executable code.

I agree that all source code is data. The insecurity comes when the product of that data is carelessly promoted to privileged executable code, without appropriate permission.

Execution of privileged instructions that can break system security should only be permitted by a certified OS kernel of manageable size and complexity. Rogue software must be summarily terminated on any attempted breach of it's allocated resources. To be secure, a system requires a secure resource management kernel protected by hardware traps.

The single user PC today is insecure because it is too flexible, in too many ways.