Latest massive attack on computing systems

[Sik]

That was an hypothetical to be fair.

The idea is that the more sandboxed each individual part is, the harder it's to exploit them if malware manages to sneak in. The biggest problem is that CPUs are pretty slow at the kind of context switching something like that would require. If that weren't the case, not doing sandboxing like this would be considered an awful practice if not outright practically negligent. Programming languages already do something like this by means of encapsulation, why not just take the logical extent and let hardware enforce it if it's feasible?

Of course, as long as performance in existing hardware would be awful, it's a no-go =P


Note to help make it clear: I was talking more about isolating them from each other so a bug can't allow them to stomp on each other (akin to how processes can't run into each other, unlike threads), not necessarily about them being completely separate programs (how much difference is between the two depends on how you handle it in the OS, I suppose).

[onlyonemac]

Granting access should always involve more than just clicking on a "Yes" button. The user should explicitly designate the resource that is to be accessed, being able to see and control which access rights are being granted. Then, he should verify by clicking an "OK" button. If there is a default suggestion, it should either be harmless (for example, access to a resource that logically belongs to the application itself) or require a key press or button click separate from clicking on "OK", and come with a warning when appropriate.

That will only make the system too complicated for the average user to use, and developers will be flooded with bug reports saying "did you grant the application the necessary permissions?" until users eventually learn to just grant all permissions by default otherwise they get frustrated and nothing works. The bottom line is, whatever you do, there's no way to protect against user stupidity.

[Gigasoft]

That will only make the system too complicated for the average user to use, and developers will be flooded with bug reports saying "did you grant the application the necessary permissions?" until users eventually learn to just grant all permissions by default otherwise they get frustrated and nothing works. The bottom line is, whatever you do, there's no way to protect against user stupidity.

Well, I'm not so sure of that. Can you actually think of a concrete example of a real application that needs to operate in this way?

[sleephacker]

whatever you do, there's no way to protect against user stupidity.

You don't have to, because when the blame is on the user it's no longer your fault. The problem is programs being able to just go haywire with your file system without the OS asking something along the lines of "Are you sure this program you just downloaded / was just automatically installed should have the permission to modify your files?". If such a question is asked and the user just clicked "yes" without thinking then it's the users fault. If random programs can be executed and can modify files without questions asked then it's bad design (at least from a security point of view). And not all users are stupid, just because all stupid users will click "OK" on everything doesn't mean smart users (or average users in situations where security is very important (e.g. computers in a hospital)) will too.

There are also ways to reduce the damage that could be done by stupid users. For example: limit file accesses to only files to which the user (implicitly by selecting the file in a file selection dialog) clicked "OK", per program files only accessible by that program (so that programs may save settings, browser history, saved games, etc...), or files of a specific type only (e.g. don't allow text editors or games to modify executable or image files). On top of that you could limit where certain files are allowed to go, e.g. don't allow "document.doc.exe" files in the "Documents" folder.
Those policies require a single "OK" on program installation at most and a few "OK"s where they make sense, if the user still manages to get all their documents and images encrypted it's their own fault at that point. Of course, no matter how much you limit the number of "OK"s, stupid users will still agree to everything, but then at least the smarter users have the ability to defend themselves.

[Gigasoft]

Most programs that you use to perform work, rather than for managing the computer itself, mainly do the following:
- Display a GUI and receive input
- Read files that are part of their own installation
- Read and write configuration and other per-user data belonging to the application
- Allow the user to open, edit and save files at any location by selecting Open, Save or Save As in a menu or with keyboard shortcuts
- Allow the user to copy and paste data by selecting Cut, Copy or Paste in a menu or with keyboard shortcuts
- Allow the user to switch between open documents by selecting them in a menu, with a keyboard shortcut, by activating a window or by selecting them from a popup list located somewhere else than the main menu
- Allow the user to open a recently opened document again
- Allow the user to print or scan something
- Connect to or provide network services
- Play a set of system defined standard sounds
- Output or record audio and video
- Interface with a custom device

Many of these functions do not require any user confirmation beyond what he would traditionally do. When the user selects Open or Save As, he needs to explicitly name a file and then press OK. When he selects Save, the filename can be displayed in the menu itself, guarranteeing that the user knows which file will be overwritten. A list of recent files can be managed by the system as well. With keyboard shortcuts, using well known standard key combinations makes it so that a file won't be overwritten or data copied to or from the clipboard by surprise, while the user thinks he is performing an entirely different action. Programs that can have multiple documents open should only be able to switch them in response to user input (and not as a result of, for example, a resize or paint event, moving the mouse or pressing a modifier key), and the current document should perhaps be named in the title bar. If the application starts painting the window on its own, it counts as having finished processing the current message. Also, a window should not receive focus unless it was explicitly activated by the user, or is a dialog belonging to the window currently with focus, or is receiving focus back from a dialog, to prevent inadvertent invocation of the Save menu command by pressing its keyboard shortcut.

A game might want to use keys such as Ctrl and V as control inputs, and must therefore not be able to enable dangerous keyboard shortcuts. This requires some kind of visual distinction to prove this fact to the user, such as a distinct appearance of the title bar. This prevents the scenario where an online game tricks you into pressing Ctrl+V to send confidential data on the clipboard to the gaming server.

With printing, you'll always get a print dialog that you have to confirm.

Other resource accesses can be made by means of a generic dialog that contains a list of selections that have to be made. For example, if the application needs an audio output device, you would be presented with a list of audio output devices, as well as the options "None" and "Default". This can be invoked at program startup, in response to user input or by selecting a menu command. The choice can be temporary or permanent (remaining in effect the next time the program starts by means of configuration data only accessible to the system). One could also have a set of checkboxes to finetune individual security features, such as whether or not to allow a window to have no title bar, and whether to allow arbitrary keyboard shortcuts for dangerous commands.

Network access can be granted to a default network provider which uses a routing table, or to a specific network interface. One could also have the option to use a set of firewall rules. An application could also be allowed to ask the user to provide an URI to a specific network resource without needing to perform any network communication by itself.

There are a few programs that don't quite fit in. For example, GIMP has Open, Save and Save As, but it also has Overwrite and Export, which do the same thing but with different image formats. This can be combined with Save, or the feature set provided by the system can be expanded to allow for one or more "Export" commands. GIMP also has several different ways to paste. These would probably be implemented as having a generic "Paste" command followed by selecting how to paste the image by pressing a key or clicking on something, or by setting a "paste mode" before invoking Paste. Also, IDEs typically deal with project files that point to a number of associated source files, as well as locations where output artifacts are stored. More research is required to determine how to support such programs. An easy solution would be to just have the user select the entire directory containing the project file, source files and outputs for both reading and writing. Naturally, if the user is about the give an application write access to his entire home directory, or a well known subdirectory of his home directory, or a per-user data directory belonging to an application from a different vendor, there should be a visible red warning text.

Well, I think you can guess what my OS is going to look like

[ggodw000]

computer/net security it is a death cycle. it has been and now and will be.

if you do not agree, think about when (if ever) will be able to reach some sort of utopian security state.
By meaning "utopian security", I meant:
- no attacker can gain access to any network that they are not allowed to under any circumstances.
- no DDOS can bring down network.
- legitimate users can freely access the network without downtime, difficult at will.
- all users are so much educated such that no social engineering attack can possibly take place.
- security professionals' knowledge, training are always one-step or more ahead of hackers'.

Do you think all of the condition can be met at some future time? If not, it is just death cycle.

[Brendan]

Hi,

computer/net security it is a death cycle. it has been and now and will be.

if you do not agree, think about when (if ever) will be able to reach some sort of utopian security state.
By meaning "utopian security", I meant:
- no attacker can gain access to any network that they are not allowed to under any circumstances.
- no DDOS can bring down network.
- legitimate users can freely access the network without downtime, difficult at will.

Authorisation is impossible in the presence of anonymity. The real question is whether you are willing to trade anonymity for security.

- all users are so much educated such that no social engineering can possibly take place.

It would be better to use authorisation based on stronger proofs of identity (e.g. biometrics, not passwords).

Do you think all of the condition can be met at some future time? If not, it is just death cycle.

I think all of these conditions can be met now. I also think few people will be willing to accept the compromises necessary.


Cheers,

Brendan

[ggodw000]

Hi,

computer/net security it is a death cycle. it has been and now and will be.

if you do not agree, think about when (if ever) will be able to reach some sort of utopian security state.
By meaning "utopian security", I meant:
- no attacker can gain access to any network that they are not allowed to under any circumstances.
- no DDOS can bring down network.
- legitimate users can freely access the network without downtime, difficult at will.

Authorisation is impossible in the presence of anonymity. The real question is whether you are willing to trade anonymity for security.

- all users are so much educated such that no social engineering can possibly take place.

It would be better to use authorisation based on stronger proofs of identity (e.g. biometrics, not passwords).

Do you think all of the condition can be met at some future time? If not, it is just death cycle.

I think all of these conditions can be met now. I also think few people will be willing to accept the compromises necessary.


Cheers,

Brendan

Just to give how much challenge is ahead:
Yeah use biometric for stronger proof identity and problem may perhaps be solved. Well, to certain degree, yes but can not cover all possible scenario:
biometric may solve following situation:
- infiltrator calls amazon user to ask for password imitating amazon tech support. With biometric, that is not possible, he can not possible give out fingerprint information.

but can stronger proof identity solve attack stemming from corruption?
Brute force attacks costs billions to establish lab and datacenter to run the attack. Infiltrator decides to bribe security officer with 10M$ compared to billion. Security officer accepts it and agreed to use his credentials in this case, his fingerprints or eye retina.

yeah yeah yeah, you can set the protocols such that 2-3 person has to use their fingerprint to gain access to resource but there is also possibility of attack.

[ggodw000]

Hi,


What is your opinion about the latest massive attack on computing systems? What could the motivation be and how could we, as OS developers, prevent that happening with systems running our OSes?

One measure I'm thinking of currently is that it would maybe make sense have every executable program registered somewhere on the disk and, before running it for the first time, have the user set various permission flags/values (e.g. able to create files, able to delete files, able to modify files, able to read files, able to send data to the Internet, etc). This way, programs polluting the disk with too many files, programs deleting/encrypting/spoofing files, etc wouldn't be able to go unnoticed before they would be able to do their job. If I recall correctly, it has been suggested before in these forums, but I can't find the relevant thread now.


Regards,
glauxosdever

That is impractical and not achievable, let's say you are installing 3dsmsx that needs to copy 3000 legitimate file and you got two choices:
- let installer toy copy all of them with single confirmation authorizion.
- your plan is to have installer to ask every one of them with confirmation to see if itcan be copied. Would you got yes or no inspecting each one of 3000 files? If course no unless you are insane enough, so you opt out for first one. Then first is itself defeats your plan.

[ggodw000]

Hi,

What is your opinion about the latest massive attack on computing systems? What could the motivation be and how could we, as OS developers, prevent that happening with systems running our OSes?

point 1. do not use windows. ever. this is the lamest, least secure system.

the attack is made possible by the smb server running in kernel mode in ring0. windows is full of such stupidity. latest HP printer drivers capable of stealing keyboard keypresses are from the same opera.

point 2. principle of least privilege. ensure your OS employs it everywhere. network driver does not need full ring0 access, neither does keyboard driver.

point 3. anything else you can think of.

I don't know much about how unsecured windows is but I know how difficult also to install patch. Here is m recent story with Wanna cry patch:
From the link for patch, I identified my Windows build, ws2012 r2 build x.
Go to sub link for ws2012 r2 build x, then I contains 6-7 patches one for 8.1 x32/x64, ws2012 x32/64 then just for win8.1. I grab most appropriate one it seems to be the one ws2012 x64 then install. It does not, saying it is not compatible with your system. You start your journey trying every 6-7 one of them. You might get lucky to find out one of them does install. If not, none of them install.

[simeonz]

These are the measures I am aware of, depending on the context:

• Access to counterfeit or infected resources. (Resource signing.)
• Storage of confidential information in the open. (Encryption with hardware security module.)
• Communication of confidential information in the open. (Asymmetric cryptography.)
• Log-in through untrusted terminal and replay attack. (Security token and challenge response authentication.)
• Theft of shared secret or token. (Biometric signature.)
• Theft of biometric evidence. (Shared secret. Liveness detection. Challenge response biometric authentication.)
• Remote access. (Mutual authentication, remote attestation.)
• Rootkit infections. (Secure boot, driver signing, executable signing.)
• Runtime infections. (Process isolation. Micro-kernel architecture. Virtualization architecture.)
• Exploits. (Sandboxing. Privilege separation. Runtime checks. MAC.)
• Data corruptions and ransomware. (Regular archival and back-up. Replication and failover.)

[Schol-R-LEA]

do not use windows. ever. this is the lamest, least secure system.

This statement really isn't fair, not because it overstates how insecure Windows is, but because it ignores how insecure other operating systems are. None of the current OSes in common use - Windows, Mac OS X, Linux, even FreeBSD - were designed with security in mind, especially the sort of security that we are discussing, because when Unix and MS-DOS/Windows 1.0 were designed, most of the threats seen today didn't really exist except as a few proof-of-concept examples and a couple of 'funny' pranks (such as the once-notorious 'Robin Hood and Friar Tuck' virus on the old Xerox mainframes).

While a significant amount of work had been done on security in the late 1960s and early, including the early development of the Capability-based Security Model, most of it was aimed at preventing either espionage taking place on-site, by a spy with access to a terminal but not to the CPU and disks, or memory corruption caused by a buggy process. More importantly, it was assumed by the researchers that access to computing would be limited to scientists, military personnel, programmers working for businesses and governments, and university students preparing for a career as one of the above. Even in projects aimed at public access to timesharing, such as Multics, the security concerns were primarily focused on password control, of monitoring resource usage for the purposes of billing, and ensuring process isolation.

Some of this work made its way into the mainframe OSes of the time. Some, such as hardware-based capabilities, proved too inefficient (though it may make a comeback someday, I suppose, given the vast improvements in hardware speeds since then - indeed, IIUC the Mill architecture is intended to have a limited form of that at the cache level).

But the Unix didn't do any of that. It was intended as a one-off, a stripped-down version of Multics that was never meant to see the light of day. Thompson and Ritchie deliberately excluded most of the security features that Multics had, because they wanted something that would be fast enough to play Space Travel (a version of the Star Trek game that was making the rounds at the time, with some added graphics influenced by Spacewar!) on a PDP-7, simple enough for two people to write in the off hours, and crucially, without all the aggravatingly bureaucratic access control and billing of Multics. In other words, it was designed to be insecure, because Multics' security was what they were trying to get around by developing it. The first versions - until after the shift from PDP-7 assembly to C in the PDP-11, apparently - didn't even have password protection, and was a single-tasking system originally (hence the punny name).

By the late 1970s, Unix was spreading through the universities as a cheap (a few thousand USD per installation, with few places needing more than one) alternative to RSX (and later, VMS) which, due to the easy access to the source code, could also be used for courses on OS dev and system utilities. It was most definitely not a business system, as AT&T were expressly forbidden from selling software for commercial enterprises until the anti-trust action broke Ma Bell up in 1982 - and they were required to provide source code for the academic and non-profit organizations which they could sell it to. Prior to Version 7, the license didn't even forbid republication of the source code, which is why the Lions book (which included the whole source for version 6) could be sold to other universities up until 1979.

Significant security wasn't really added to Unix until 1981, and then only because ARPAnet's upcoming switch from NCP to TCP/IP included a requirement that systems have some minimal security support (a similar story occurred ten years earlier with ITS, which was passed over by ARPA in favor of Tenex for the primary nodes due to it not even requiring passwords at the time). By then, it was already far too late to retro-fit a proper security model, even by the standards of the time.

Its descendants never were able to fix this, either, as they were still focused on other matters. Apple's priority is UX, while the Linux community has always been diffident about anything that restricts user freedom, so neither group has really made any attempt to change things from the Unix model. FreeBSD and its relatives have done more, but are hamstrung by bug-for-bug compatibility issues, and are pretty leery of restricting users as well. More importantly, they all could coast on the fact that a bigger target existed - Windows - meaning that the brunt of the attacks hit someone else.

MS-DOS came from a completely different tradition as well. When 'micro-computers' (home computers, personal computers) started to appear in the mid-1970s, they were so limited in what they could do - 4KB or less of RAM was typical (the first one, the Altair 8800, shipped as a kit with a memory board that could hold 256 bytes, which filled the entire board with ICs), paper tape was the dominant storage medium for the first couple years (and the reader was an add-on - for the first several months, the primary I/O for the Altair was the toggle switches and LEDs on the front panel), and operating systems were considered an unimaginable luxury - that just getting them to work took precedence. In 1977, as the generation 1 PCs such as the Altair, IMSAI, and Sol gave way to the Gen 2 pre-built models such as the Apple II, the TRS-80, and the Commodore PET, the tape and disk operating systems were focusing just on getting the data in and out of the storage media - most of the file systems didn't even have equivalents to the Unix RWX bits - and the idea that anyone would bother intruding on a machine meant for, and only suited for, mildly obsessive hobbyists would have been met with scorn.

MS-DOS arose in the third generation of microprocessor-based personal computers, and like CP/M, was written with no consideration for security to speak of. The file system had no subdirectories, access bits, or provision for user-defined hidden files until version 2.1, which borrowed a lot of things from Unix (which, as I already stated, wasn't exactly designed with security in mind). No one thought that these simple, monotasking, disk-oriented file managers would ever need more.

The rise of the public Internet took everyone by surprise. No one had any expectation that computers would be as ubiquitous as they have become. We are stuck with operating systems, and a model of operating system design, which treats security as a problem instead of a solution - one which puts it as the very lowest priority, at best.

And it isn't as if companies haven't tried to sell the public more secure systems. MS and the Linux Group are painfully aware of how terrible their security models are, but trying to fix them always runs into user opposition due to it being intrusive and restrictive. Hell, MS had to remove security features from the NT kernel to make XP palatable to the consumers, not due to technical limitations but because focus groups shown the beta of XP complained about how much hassle it was. The intrusive security warnings in Vista were one of the main complaints about it, too, so they toned those down in 7, knowing full well that it would compromise security. The public simply doesn't care about security.

For the most part, neither do corporations or governments. The break-ins at Target, Sony Pictures, the Social Security Administration, and other places were all things which could have easily been avoided, but the preventatives were all deemed too expensive and/or complicated to implement - not just before they happened, but afterwards, too. It is cheaper and easier to simply swallow the costs and consequences than it is to fix the problems. The entire software industry follows the same line of thinking that gave us the Pinto Memo.

Think you can do better? Probably not. The majority of posters here seem to forget the hard icky parts like security, while those who do take it seriously such as Brendan and myself talk a good game but have little to show for it. Most of the really useful information on security is buried in research journals which we don't even have access to, never mind read. Even if one of the operating systems here got some traction - which is about as likely as the developers' feet getting traction on the surface of Mars - the odds are it would be one which succeeded in part because it ignored the costly and time-consuming security operations.

You know, like Unix, Linux, Mac OS, and Windows do.

TL;DR - It isn't that Windows is less secure, it is that the others can get away with insecurity as long as Windows is around to draw fire from them. The OSes we have now? Insecure by design, and they only succeeded in the first place because they were. Users, and hence developers, see security as a nuisance rather than a protection, meaning a secure OS will always fail in the marketplace, at least if it doesn't have a killer app of sufficient importance that it overcomes the resistance to improved security by the users.

PS: Riddle me this, Brendan: if the secure computing niche you claim to be targeting exists, and is large enough for someone to make a profit filling it, why hasn't it been filled yet? If your answer is anything along the lines of 'because no one has been smart enough to fill it before,' then I recommend you step back and take a long, hard look at your assumptions. Dozens, if not hundreds, of firms have tried to sell operating system security, and all failed, even when they had genuinely superior products; these businesses range from one-man startups to giants like IBM, Oracle, DEC, Microsoft, and General Dynamics (yes, the monster all-encompassing defense contractor the US government is so in love with tried to tackle this, more than once), each of whom threw billions down that rat hole. What makes you think you'll do better?

[Sik]

The other day this was being brought up:
https://blog.qualys.com/securitylabs/20 ... tack-clash

tl;dr tricking a program to access an offset far enough away from the stack that it runs into the heap.

It hits me that this can be generalized to any memory access, since all memory alloted to a process is present in the same address space - and despite the suggestion there, no amount of guard space between memory regions will do the job, because all that does is just require a larger offset to cause an exploit, and offsets can be as large as the whole address space.

Looks like at this point we're going to need to rethink how the whole hardware works, period. Yes, you could do boundary checks, but that only helps mitigate exploits in your program, that won't help with other programs that may not have been programmed carefully. Also: worth noting that programming languages already tend to isolate what code can do (this is what scoping rules do) but that only works as long as the program is functioning normally (exploits disregard those rules since they don't go through the compiler), maybe it's time to have it enforced at the CPU level. But that requires having much faster context switches... (or something that works to that effect at a minor scale, at least - e.g. not a full context switch but just having a second set of restrictions)


I'm seeing news about exploits coming up really often lately, I have the feeling that in a few years our OSes (and possibly new hardware) will have changed to the point they only barely resemble our current systems anymore.

[Schol-R-LEA]

Oops, I did it a... no, I am not going there, Eris damn it!

I was still editing my earlier post when you posted this, Sik, so you may want to read that post's changes; they are relevant as to why security is never a top priority for customers and vendors alike, and probably never will be.

[Brendan]

Hi,

...

I want to find a convenient excuse to cut & paste all of that into the wiki.

PS: Riddle me this, Brendan: if the secure computing niche you claim to be targeting exists, and is large enough for someone to make a profit filling it, why hasn't it been filled yet? If your answer is anything along the lines of 'because no one has been smart enough to fill it before,' then I recommend you step back and take a long, hard look at your assumptions. Dozens, if not hundreds, of firms have tried to sell operating system security, and all failed, even when they had genuinely superior products; these businesses range from one-man startups to giants like IBM, Oracle, DEC, Microsoft, and General Dynamics (yes, the monster all-encompassing defense contractor the US government is so in love with tried to tackle this, more than once), each of whom threw billions down that rat hole. What makes you think you'll do better?

Reasons I hope I might do better are:

• The main "selling points" all have nothing to do with security. It's all about scalability, spreading load across a LAN to reduce hardware costs, reducing maintenance costs by making many computers act as one OS (plus various unrelated "convenience" features).
• Because it's aimed at "groups of many computers", it makes more sense for business use (where security is more valued) and doesn't make so much sense for small/single computer scenarios (where performance is more valued).

However; the nature of the project means that bad security (and bad fault tolerance) would be detrimental. For example, if a single "disgruntled employee with physical access" can compromise a group of many computers that an entire company is depending on, then the entire project is doomed.


Cheers,

Brendan