Bounty Proposal: Increase RISC OS Security

This is a fairly open-ended topic and maybe not best suited for a bounty but I think its something that merits further discussion.

If we had a bounty set up it might encourage someone with knowledge of system security to take a look at RISC OS and offer in the first instance advice on what elements are insecure.

The outcome of this study would be a list of improvements to the core of RISC OS to make it more secure by design. There could also be a document for anyone developing any new applications to provide advice on any security related issues.

In time we will hopefully have a fully functional web browser and it would be nice to be able to use RISC OS without fear of anyone intercepting, stealing or using our data. As the number of users for RISC OS increases so too do the risks, but since “security through obscurity” is a fallacy we should perhaps be concerned even now.

Glen: paper bags have more security than RISC OS. Once you get to malicious code execution you have full OS rights and can access the entire memory map with fairly trivial effort. Want to write to the Boot sector of a file core device? Be my guest…Keylogging? Sure – if you want. Snoop on network traffic? Why not.

RISC OS has many strengths for being simple and extremely lightweight. The cost is that security is effectively non-existent and couldn’t easily be improved without it being a different OS.

However don’t underestimate security through obscurity. The code author who crafts such things for snooping on RISC OS, whilst not having to toil too hard, will not be rich (since they won’t get many customers!) and likely knows his/her target. And to be honest if you’re going to write custom code for targeting an individual – you probably would succeed regardless.

If we had a bounty set up it might encourage someone with knowledge of system security to take a look at RISC OS and offer in the first instance advice on what elements are insecure.

The answer would probably be “everything”.

The outcome of this study would be a list of improvements to the core of RISC OS to make it more secure by design.

The biggest problem (as Eric has said in the browser thread) is that everything runs as root. So the main way we’d want to increase security would be to prevent user-mode code from being able to switch to privileged CPU modes (or at least stop them from doing it without the permission of the user/system). E.g. OS_EnterOS, OS_AddCallBack, OS_Claim, etc. would all need modifying.

We also need a much stronger idea within the OS of what a task/process actually is. Partly so that the security checks can check for permissions against the right thing, and partly so that we can start partitioning away things which should be private to a task (memory, file handles, sockets, etc.)

Making use of the nonexecutable page flag would also be wise (and limiting how much a task can change the memory map via OS_SetMemMapEntries, etc.)

Enabling high processor vectors wouldn’t go amiss either.

The code author who crafts such things for snooping on RISC OS, whilst not having to toil too hard, will not be rich

and will provide the base code for a good handful of diagnostic utilities in the process. There are actually positives.

The biggest problem (as Eric has said in the browser thread) is that everything runs as root. So the main way we’d want to increase security would be to prevent user-mode code from being able to switch to privileged CPU modes (or at least stop them from doing it without the permission of the user/system). E.g. OS_EnterOS, OS_AddCallBack, OS_Claim, etc. would all need modifying.

One good thing could be to have strong file locking mechanisms, to protect part of the disc from modifications.

One other thing would be to have a SSL module, that people could use for web servers, etc. The lack of SSL is really a problem for some of my professional projects.

For security, isolation (with virtualization) could be interesting too.

One other thing would be to have a SSL module, that people could use for web servers, etc.

Got one, so has anyone that bought the NutPi package or NetFetch…

Or were you looking for something that was totally free?

Steve: Agreed – the reason this is GOOD in RISC OS stuff is that you can do what you like to the box.

Should we be afraid that there’s no security? Probably not – I’m always reminded of XKCD’s slant on this: http://xkcd.com/538/

Security through obscurity will protect you right up until someone wants specifically /your/ details – but then at that point you are the $5 wrench away from being vulnerable anyway.

Or were you looking for something that was totally free?

I mean a free one (included in ROS 5), both for client and server applications.

I mean a free one (included in ROS 5), both for client and server applications.

Fair enough, but the NutPi isn’t that expensive particularly when you consider how much is on it.

Acorn did have an SSL module…Called AcornSSL!
It was part of !Browse.

If you want to use the R-Comp SSL module I believe they will supply you. IIRC they haven’t put up as download as they like to know your use. An email request costs nothing:-)

Could the R-Comp SSL module be used to replace the Acorn SSL version in !Phoenix – it’s SWI are different?

Although, nobody’s actually going to use security software that isn’t easy to get. Asking someone to pay anything or e-mail anyone to get security software will result in them just using a less secure option, or using a different platform. Then again, in this case, using a different platform is the better option.

And, is the R-Comp SSL module this? http://www.arsvcs.demon.co.uk/webster/download/ssl.htm (404 on the actual download.)

Because I’m not actually finding it anywhere in the copy of NetFetch that came on my copy of NutPi… Also, I’m guessing that it’s based on an incredibly ancient OpenSSL, which presents its own problems for security (both a lack of support for modern security protocols (and likely only supporting insecure protocols), and vulnerabilities that allow key material to be grabbed (unlikely on RISC OS) or potentially allowing an attacker to forge a site).

Now, as far as adding security to RISC OS… I suspect that by the time you did it, the result would be an incompatible OS that happened to follow the style guide’s UI specifications. It wouldn’t be RISC OS any more. My comments were more along the lines of, if you’re doing something where security matters, don’t use RISC OS.

Admittedly, RISC OS is an extremely obscure platform, and the likelihood of a RISC OS-specific attack is rather low (I could see it happening, though), but how many people are using, say, Firefox 2.0.0.12 or 2.0.0.20 to do their banking? There’s plenty of Firefox-specific platform-independent attacks out there, I believe, against ancient Firefox. And, consider how much RISC OS software is based at least in part on *nix ports, and how much of it probably hasn’t been updated in ages (both because the developers don’t have time to keep new versions ported back to RISC OS because “it still works”, and end users both distrust package management and don’t rush out to update things without a centralized update source). All of that is potentially vulnerable against attacks against those specific programs, and who knows what’ll happen there.

It’s in PlingNetFetch.Apps.!Hermes.Resources here. There’s three versions called Secure, Secure32 and SecureG. Can’t recall what the difference is. These are dated 26 Nov 2005, 09 Dec 2002 and 26 Nov 2005 respectively.

and the likelihood of a RISC OS-specific attack is rather low (I could see it happening, though),

Oh… Wow.
<facepalm>

These are dated 26 Nov 2005, 09 Dec 2002 and 26 Nov 2005 respectively.

A decade old at best.

You do realise, I hope, that as a result of the most recent SSL screwup (FREAK), that the common fix means that no versions of Internet Explorer on XP (if anybody is using such a combo still) will be able to connect securely. It doesn’t work correctly, though I don’t know the specifics as I try to avoid using IE.
How does this software hold up? It probably predates Heartbleed. But FREAK and POODLE? And that’s just two that come to mind. Does it support TLS > 1.0?

And that’s where I was going with the comments about “likely only supporting insecure protocols”. Seeing as TLS 1.1’s RFC was in 2006-04, somehow I’m not thinking those modules support it. And, I believe anything older than 1.1 is now deemed exploitable to the point of being untrustable…

Now, while this is only a concern if someone can actually get in the position of man in the middle, and in a residential environment that’s unlikely (but still possible with attacks against common residential routers, which can often happen in an automated fashion, and modern routers have enough spare CPU power to do some packet inspection without the user noticing that much)… it’s also worth noting that there are some mobile RISC OS platforms. While RISC OS currently doesn’t support 802.11, once it does, MITM attacks become a much bigger concern.

Ever wondered why you’re never asked to update your certificates? Rcomp’s SSL module seems to simply take a “looks legit” approach without actually checking whether things are valid at all. Talk about man in the middle! Alexander Aussendorf has been working on a TLS module of his own but that’s all I know about it.

Oh, so R-Comp’s module can get Superphished, without even having Superfish installed.

Awesome.

I’m not actually sure what OpenSSL NetSurf’s built against – the build instructions say to use 0.9.8’s patches from the autobuilder (0.9.8 being a legacy branch that is still maintained), but the autobuilder SVN appears to only have 1.0.0 patches, and 1.0.1 is the current branch. Not sure how that’s working.

In any case, I am thinking that there is something that can be done about security – figure out what RISC OS SWIs are inherently vulnerable and unnecessary for use by well-behaved software, and then declare them deprecated (or deprecated for certain purposes) in the PRMs and style guide. Doesn’t do a thing about current software, but it helps in the future. Also, actually use filesystem permissions – even if the user is still running as root by default, making it easier for a user to do things unprivileged and then elevate as needed would be nice.

In any case, I am thinking that there is something that can be done about security – figure out what RISC OS SWIs are inherently vulnerable and unnecessary for use by well-behaved software, and then declare them deprecated (or deprecated for certain purposes) in the PRMs and style guide.

If you ask me, deprecating them won’t do much. We actually need to follow-through and delete them.

For compatibility we could move the insecure SWIs into a softloadable support module (mapping them onto secure forms, and/or adding some kind of UAC-style popup whenever an app tries to call them). But that would be a separate download from the core ROM + disc image. Security-conscious users/developers can run their system without the support module, but anyone who needs to run legacy code (so about 99% of users, judging by how much RISC OS software is effectively unsupported abandonware) can use the support module.

Well, the UAC approach has its upsides and downsides, but implemented properly, I could see it being the best bet for now.

Microsoft actually set up UAC in Vista to intentionally be annoying to end users, to encourage them to complain to software vendors. (This is part of why the UAC prompts make such a big deal about the publisher of the program.) Of course, what Microsoft failed to account for with that strategy was two factors:

• When “Publisher: Microsoft Corporation” appears on half the dialogs, you dun goofed
• “Well, it didn’t do that on XP! Vista sucks, I’m going back to XP!”

A UAC-like implementation that could be done immediately (after the deprecated APIs are identified), really, could be an application whitelist application. Upon first call to a security deprecated SWI, a UAC prompt could be thrown up to alert the user that the application uses insecure RISC OS functionality, to check if a newer version is available, and if not, that there are risks to running the application. If the user chooses to continue, that preference is saved and the user won’t receive another prompt for that application only.

Of course, that would work better if there were a binary signing system on RISC OS, but hey…

Edit: And I’m thinking things could be enabled in stages, like so:

1. Deprecate unsafe SWIs, add Security option to !Configure, allow users to enable unsafe SWI whitelisting if wanted
2. At a certain milestone, enable unsafe SWI whitelisting by default
3. At another milestone (when those SWIs can be safely emulated, or software can reasonably be expected to not use them at all), remove the affected SWIs entirely

Cancel or Allow

As regards SSL and security, unless we have developers with time to maintain and patch this is all fantasy.
My thoughts would be to write a module interface to SSL using libressl
Or update the secure socket module – which is also a possibility.
Also we would need a “ROOL Updates” or via !Store update application as well, to ensure all CA certs are up to date.

It would be nice to have an selinux/apparmour integration style method, but then I feel going down a core OS redesign route would be a better idea and design security modules in from the start.
Not necessarily a good, or a viable idea either.

People do tend to pick on SSL as a target, but the recent glibc security issue was way way worse than all of the SSL issues combined IMHO.

Mind you, !PackMan already exists… it’s just that a lot isn’t packaged.

It’s probably too late to mention that I haven’t used NetFetch in a long while so don’t know if the modules I looked at are current.

I’m not actually sure what OpenSSL NetSurf’s built against

Depends on who’s building and when they built it. Builds that come from us are currently using version 1.0.1k.

the build instructions say —

You managed to find some legacy documentation. John-Mark has removed it now.

Ever wondered why you’re never asked to update your certificates?

NetSurf could be a bit clearer in this respect too.

Going to https://www.riscosopen.co.uk/forum/posts throws a big error on all of my systems. It also does on NetSurf as a depressingly small window that says "NetSurf failed to verify the authenticity of an SSL certificate. Please verify the details presented below.

I can see Subject: www.riscosopen.org Domain Control Validated and that the certificate is valid until 2016. Issued by GoDaddy who is to be trusted until 2031/2034.
At no point did NetSurf clearly indicate the obvious – this certificate is not for the domain you’re looking at!

You know, like Android…

NetSurf does specify at the top that the certificate is Subject: www.riscosopen.org as stated above, but you have to be paying close attention to catch this.