Latest massive attack on computing systems

[glauxosdever]

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

[matt11235]

Maybe you want to have a look at mandatory access control?

[dozniak]

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.

[glauxosdever]

Hi,


The point of this thread was to look for specific solutions to implement in our operating systems to prevent such attacks. Not using Windows is not a solution in itself, since Linux or our operating systems might actually have worse vulnerabilities than Windows. The principle of least privilege is, I'd say, too vague since it doesn't explain what actually is permitted by specific programs and what not. Mandatory access control can also be implemented in many ways, and possibly in currently unexplored ones.

This is definitely a topic every developer aiming for a secure OS should be interested in. So, let's put ideas in here!


Regards,
glauxosdever

[onlyonemac]

There's two issues when it comes to computer security in this situation:

1. Granting privilege to components that don't or shouldn't need it
2. Vulnerabilities that allow software to be used in ways other than it's supposed to work

These are actually two separate issues, and should be treated as such.

The first issue deals with situations where applications can access parts of the system without the user giving them permission to or without the user being aware of it, without having to use exploits to get access. For the first part, the right access control system prevents most risks. Operating systems like Windows, which give every process access to everything, are the most susceptible to these kinds of attacks. That's why it's so easy to have, for example, a trojan horse on Windows that sends your personal files to a remote server in the background, and the only way to detect this is by actively monitoring disk and network activity with heuristic algorithms (which is a task that a lot of antivirus applications struggle with - does your antivirus software ever say "suspicious network activity detected", or does it only report known threats by name?). Linux by default doesn't really help in this regard to be honest, although at least it gives you the tools to harden your system if you can figure out how to use them (SELinux, kernel namespaces, chroot, and so on). In my opinion, Android is the best in this regard. It gives a full list of permissions before installing an app, and enforces these permissions at the OS level (they even apply to native code thanks to the "one user per app" model). In more recent versions, it also displays a confirmation dialog before granting certain permissions at runtime. The only thing that could make this better is if the permissions were more fine-grained (they're actually quite fine-grained from the developer's point of view, but they're "simplified" for the user), and if Android confirmed and kept track of permissions granted at runtime seamlessly instead of requiring the developer to explicitly check for and request permission every time they need it.

The second issue deals with situations where applications aren't supposed to be able to access particular parts of the system, but are able to get access because of a bug/vulnerability in a piece of software that has whatever access they require. For example, even though javascript code isn't supposed to be able to read the user's files, it may be able to gain access by exploiting a vulnerability in the web browser, which does have access to the user's files. Depending on where the vulnerability resides, access control may help to reduce the impact of such a vulnerability (e.g. if the web browser had to explicitly get permission every time it accessed a file (with user confirmation by the kernel), javascript code wouldn't be able to read the user's files even if there was a vulnerability in the web browser). But this isn't always the case, particularly when the vulnerability lies in system components or other components with access to important parts of the system. The main defence against these attacks is secure programming. Checking for buffers that could overflow, avoiding executing data (including as scripts), particularly data that's obtained externally, such as from a file or over a network (this becomes tricky, because at some point a piece of code stored in a file or downloaded over a network has to be executed). Judging from the past, it seems that Windows is again pretty terrible in regards to this kind of security. This is the main area where Linux is a lot more secure, due to better-written code - while it may be possible for any process to access the user's files, the user has to actually execute the code themselves; it's a lot harder to make code execute without the user requesting it on Linux than it is on Windows, because there are far fewer buffer-overflow vulnerabilities. But the truth is, this is always going to be a risk even with a solid permissions model, and the only defense is to read through code many times over, run it through analysis utilities, and take every other measure to minimise the impact of a vulnerability.

Slightly unrelated, but I also think there's too much focus on making the system secure rather than protecting user's data. It's always a Bad Thing when code is able to get system-level access, but in reality it can probably do just as much damage from the user's point of view without system-level access. Sure, it can't plant itself into the system and make it difficult to remove, take control of the user's input devices, or spread itself via a hidden partition on a USB flash drive, but it can still access and destroy the user's files and send and receive data over the network. This is why access control is so important, because ultimately it's not the integrity of the system that matters but the privacy and integrity of the user's data.

[Brendan]

Hi,

I'd be tempted to consider the problem an ingrained cultural problem, rather than a technical problem.

Before the Internet became ubiquitous there was a lot less need for security - most software developers (and most OS developers) really didn't need to care too much. Then the Internet came along and everything changed. Instead of starting to care about security a lot, software developers decided they can release even worse code than ever before (and then use the Internet to update their dodgy/buggy messes monthly/weekly/daily, without even bothering to offer an apology for releasing vulnerable software in the first place).


Cheers,

Brendan

[glauxosdever]

Hi,

I also think there's too much focus on making the system secure rather than protecting user's data.

The latest attack involved destroying/encrypting user data, which unfortunately didn't require explicit permission from the user. And this exactly proves your point, and this is something we, as developers, should be more than concerned about.

software developers decided they can release even worse code than ever before (and then use the Internet to update their dodgy/buggy messes monthly/weekly/daily, without even bothering to offer an apology for releasing vulnerable software in the first place).

I'd be tempted to suggest that some developers do it on purpose, so people pay for newer versions that fix previous vulnerabilities (while including new vulnerabilities). I'd be tempted to suggest that some developers do it on purpose, so people have the illusion that anti-virus is the only way to keep them secure and pay for it. I'd be tempted to suggest that people writing malware may actually work for anti-virus software companies, so people feel more need for anti-virus software and pay for it more.

Of course all of this is nothing more than speculation, but this is what I'm suspecting.

-----

While we are at the topic of security, it may be possible that your computer hardware itself is not secure. There is the Intel Management Engine, the AMD "Secure" Processor, etc. There have been multiple reports about such built-in "features" being malicious. The epitome of such a report would probably be called: Intel x86 considered harmful.
Note: I have not confirmed myself that it is actually the case, but I wouldn't play indifferent about this either.

Anyway, I think it would be very hard for an OS to prevent this happening if the CPU manufacturers enforce it.

-----

Curiously, the Security wiki page hasn't been updated since two and a half years. Maybe some security experts could add something to it?


Regards,
glauxosdever

[Sik]

From what I gather the problem is worse than it sounds:

• For home users... blame Microsoft on this one. A lot of people disabled updates because Windows had a tendency to reboot whenever it felt like or force you to wait while it was installing an upadte, which was horribly annoying. Running Ubuntu here with automatic updates enabled and the only time I ever notice them is if some driver broke, because it just downloads the updates and then the next boot they "just work" (and if something broke, I can safely roll back to the last update (which files are still present) and wait for the next one to inevitably fix the issue). Why Microsoft can't get this one right is beyond me.
• Enterprise tends to avoid updates as much as possible because they run (possibly customized) software that isn't easy or even feasible to fix and if an update breaks said software, they can be screwed, not to mention the hell of ensuring every single system is correctly updated.
• Expensive potentially dangerous equipment like MRI machines requires government certification to be legally used (as in every individual machine), and patching the software voids this certification. Having to recertify before it can be used again can take ages and cost lots of money (which they won't have), which is precisely what you want to avoid.
• You can't just airgap them either, since there's a ton of data that needs to be sent to the hospital servers (e.g. to store in patient records or whatever). It only takes one infected machine in the network to completely screw things up, and airgapping the whole network is not feasible because organizations may be starved and not be able to afford maintenance of in-house servers (ugh).
• Replacing them is even a bigger problem, since they cost a lot of money (I mean millions) and may require taking down some walls of the building just to put them in. And you'll still need to wait ages before you're legally allowed to use it. It's in your best interest to keep these machines usable at all costs.

Obvious suggestion: regular back-ups so you can just image them back in.

Anyway: as programmers, the most realistic thing we can really do is to just try to keep our software as bugless as feasible (sandboxing won't help if the vulnerabilities are in the sandbox itself). As for expensive equipment which is guaranteed to be its own beasts, well I guess we can do things like using non-standard variants of protocols (e.g. different port numbers and such) so attackers at least have to explicitly target it, and maybe do stuff like provide a factory restore in ROM (i.e. can't be overwritten at all) so in the worst case the machine can be restored back to an usable state, even if you need to configure it up again. (you may also have lost a few recent files, but anything meant to be stored permanently would be kept elsewhere anyway). This won't prevent all danger but at least gives some room for recovery (and hopefully, watchdog timers will make hardware immediately stop whatever it's doing if the machine got infected in the middle of a critical operation).

The bureaucratic side of things is a bigger problem though. We're in a time where applying security patches constantly is a must. There should be a way to make this easier without requiring recertification. The biggest issue is convincing politicians to actually care about this. Probably what will happen instead is them passing another anti-cybercrime law to look tough and that's it...


PS: why the malware author thought that a new strain without the kill switch was a good idea is beyond me, they already have everybody after them O.O

[Kazinsal]

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.

Please go on about the security of a version of Windows from 2001 and how that reflects on a version of Windows from 2017. Please. It'll be so enlightening.

You know, there's a real good reason the overwhelming of the people with desktops are using Windows.

[Geri]

there's a real good reason the overwhelming of the people with desktops are using Windows.

advanced it experts should avoid to use any version of windows operating system.

[dchapiesky]

hmmm....

you could try:

1) every executable signed & distribution is controlled, i.e. the App Store, presumably with the bells and whistles such as filtered opcodes, no assembly, and code review...

You just shoved the problem up the stack to application developers who for some reason need complete access to your contact list, your emails, your photos, and your password store for a simple recipe app. If, as a company, you police your pleasant little ecosystem and do a good job of keeping out the rif raff you will suffer one of the following: a) you let one through and your advertising is now moot due to social media, or b) you get so big with your product that you are sued for restraint of trade by those jealous of your monopoly and summarily broken up like AT&T... (why else do you think Microsoft let Apple live and now why Apple lets Microsoft live?)

2) custom "managed" language - ala Java, .Net, etc... in a homogeneous ecosystem....

Well this is all well and good until someone has to manage the keys and perform revocations... who do you trust? what about zero day? it's a crap shoot. And it moves the problem to whether or not you have a network connection and how much do you trust those these days?

3) partitioned OS's.... MiLS OS's... yada yada... not for the faint of heart but good... right up until you have to distribute config info to more than say.... 1 computer (scholar - what was the highest level Win NT ever got certified for in the Orange Book? If I recall it could not actually be connected to anything to maintain the rating). The ongoing docs are lethal to morale and again... who do you trust? This model moves trust to actual people so at least you can kill them and their families if they rat you out to another government.

4) as some job advertisements on the 'ol forum suggest - some go for security through obscurity - keeping their code and their OS's tight and their non-disclosures up-to-date!

This BY FAR is the best way to go if you have the luxury. People who are about to quote torvolds and say more eyes is better can shove off. I am not interested in finding bugs. I am interested in a secure system for my customers... The OS's in this section (4) are custom built - contain no code other than what it required - are closed ecosystems - and may or may not use code signing etc... trust being given via cash money in their pockets from their customer's banks accounts (and non-disclosure agreements)

Presumably enough money has changed hands that the customer knows the risks of a custom OS and has performed due diligence such as code review, internal and external audits, and 24hr tracking of the children of the vendor's CEO, CFO, and CSO.... (lookup clawback clause if you wonder about this tidbit)

---------

at the end of the day - it will always be a crap shoot....

[thepowersgang]

This sort of attack (Well, ransomware in general) has been on my mind during the design of my current OS project. (That said, it's not gone far).

The solution I was going for was that untrusted programs (or even all programs) can't open files themselves (outside of their install/data directory) - Instead they as a per-user server to open a file (which might ask the user to pick the file they want to open).

This sort of approach would cut off ransomware directly - the tool wouldn't be able to modify (or even access) files without the user being informed that the file is being opened. It might not outright stop a determined piece of malware, but it would require more design work to make it be reasonable for it to ask for access.

[bluemoon]

Security is always tricky. Often security is traded for convenience (which many don't agree, but we aren't majority). There are multiple path being explored
1. Tradition ACL. It works most of the time but we all know the root is evil.
2. Capability (e.g. Android). It getting tricky to consolidate and group permission. It become unusable if you ask the user to review one thousand permission detail.
3. AppArmor. Not usable for non-technical, but they may "trust" the maintainer/administrator to setup proper profiles which give fine controls.

But it's only half of the story. The fact that Windows lack support for easy-to-use backup out of the box, without requiring extra hard disk, is also to blame. Modern OS should improve the backup facility and provide support even down to FS level (versioning), and provide protection on those backup, which basically nullify any ransomeware.

[Solar]

The solution I was going for was that untrusted programs (or even all programs) can't open files themselves (outside of their install/data directory) - Instead they as a per-user server to open a file (which might ask the user to pick the file they want to open).

A concept I've been mulling over for Pro-POS back in the day as well. A program may access it's "own" files, or those deliberately put into a "file DMZ", but nothing else. Sharing files between programs requires authorization by the user. Something along those lines.

[Brendan]

Hi,

For things I'm doing:

• Micro-kernel. The attack surface for a monolithic kernel so massive that you're guaranteed to have "privilege escalation" vulnerabilities.
• Versioning file system. This means that nothing can modify a file (you can only create new version/s of a file). Combined with "delete only marks files as deleted and doesn't actually remove anything" this means that crypto-ransomware can't prevent access to the original unencrypted versions of files. It also means you can do "global file system roll back" relatively cheaply, just by marking newer files and directories as deleted and "undeleting" files and directories that were deleted after the time you're rolling back to.
• All executables digitally signed by the publisher's key; where you must be able to identify the publisher (publisher ID determines which private key is needed to decrypt the signature), and can have a blacklist of "known bad publishers".
• All executables given their own "userID" when they're installed; where an executable's "userID" is used for file system permissions. To access files using the currently logged in user's "userID" an executable has to ask the "station manager" to do it on its behalf. Note: "Station manager" is a layer that sits between user related device drivers (video, sound, keyboard, mouse, ...) and the GUI, that handles things like user log on/off, etc.
• No "all powerful admin/root". There are only "infrastructure officer" and "security officer" roles; where both of these are only able to use a special "management tool" designed for their role. Infrastructure officers and security officers are not able to use normal applications or use any files.
• Role-based access control and a "security manager" service. This is used for more than just file system permissions - any software or service can ask "security manager" to create a new security category, and ask "security manager" to do permission checks for its security category. For a relatively random example, maybe the networking stack creates a "TCP/IP security category" and assigns different access levels within that category to different TCP/IP ports, and uses "security manager" to check if executables and people have access to TCP/IP ports. Security officers (using their management tool) would grant executables and users a "min/max access level range" for the network stack's "TCP/IP security category". Note: Infrastructure officers and security officers don't take part in the role-based access control system, because they're only able to use the special "management tool" designed for their role. E.g. a rogue security officer can not give themselves access to confidential files.
• Only infrastructure officers are able to install executables. When executables are installed they're given "default access" (which is no access to anything other than the executable's own files). Security officers (using their management tool) have to explicitly grant additional access. Note: This means that at least 2 people need to conspire to install malware - one rogue infrastructure officer isn't enough (because they can't grant access), and one rogue security officer isn't enough (because they can't install it).

I also have a bunch of other security features ("no execute" page protection, physical address space randomisation, IOMMU restrictions for drivers, quotas for various resources, etc).

Of course the security for my OS is designed for larger distributed systems (lots of computers and lots of users). For a traditional desktop OS (e.g. one computer with one user) it'd be far too painful to tolerate. I'm not entirely sure if I'm going to do anything about that - I might (or might not) add some kind of "relaxed security mode" where a normal user is able to do everything themselves.

I'd also point out that my role-based access control system currently scares me. It's something I've not done before (previous versions of my OS had "vaguely unix like" file system permissions and not much else) and something I have no experience with, and I'm forcing it into my OS design without really being able to foresee all the consequences.


Cheers,

Brendan