Bounty Proposal: Increase RISC OS Security

BTW: https://cve.freakattack.com/ and https://cve2.freakattack.com/

Look for “EXPORT” in the gibberish returned here: https://ciphers.freakattack.com/

And for colourful text: https://www.ssllabs.com/ssltest/viewMyClient.html [needs JavaScript; NetSurf appears able to run enough to get useful results]

Hehe… I’m using an older Firefox (got sick of them ***sing with the UI at every incarnation), it doesn’t support TLS1.2. NetSurf does. :-P

Just my 2p: If any serious effort were expended trying to make RISC OS robust against deliberate attack (malware), it could no longer be considered the same platform because too much software would simply stop working. Most people will not have had cause to reverse-engineer as much software as I have (working on Aemulor), but I can tell you that even ‘pure’ application code such as Impression uses SWIs such as OS_EnterOS.

Effort expended at preventing accidental crashes, ie. “Increasing RISC OS Stability” is another matter, and definitely to be encouraged, benefitting both the users and the developers.

Which is part of why I proposed the “deprecate and alert, then emulate/remove” approach – it means that software would be written/modified to use safer SWIs (all of this assuming that a safer SWI is available, of course, to do the same thing), and then after a period of time with enough software fixed, the unsafe SWI could be removed.

And to have stronger file locking mechanisms, to protect part of the disc from modifications :)

I explain:

Locking could protect all strategic directories from any modification, but also prevent the launch of code from other directories. So every existing applications will be protected against changes and viruses. No need to fix them.

On the other hand, you could allow applications in unsafe directories, but only if marked with a CRC signature provided by an integrated anti-virus. If the application code is changed or unknown, it’s blocked. Of course, as much signatures as possible should be provided in a database, to secure downloads (I can manage that).

Some completely non protected directories could be provided too, for developers.

Example: all modifications in Boot and Apps will need to validate the operation (with fs_unlock mechanism). For the others, a CRC signature will be calculated and verified. If the App is modified, it’s blocked. DDE directory could be fully unprotected.

Today, it’s protected or non protected, and mainly for Boot.

Tomorrow, it could be protected, monitored or unprotected, directory by directory. By default, Boot could be protected, Scrap & DDE & Cache unprotected, all the others monitored.

Unless I’m wrong, which is often! Bypassing that kind of protection on RISC OS would be a piece of cake I would imagine unless serious work is done elsewhere first.
If you’ve got unrestricted access to the hardware (I’m thinking memory specifically), I would think filesystem protection would be of limited use.

I know (> “to have stronger file locking mechanisms”).

As a side comment, I’ve provided source code to our SSL module on demand to those actually interested in developing it further – sadly nothing has come of it as yet, I think in part due to the age of some of the components used (it was a messy job porting linux code at a time when GCC couldn’t do modules). The code is commented to some degree, and anyone seriously interested in taking it forward should contact me directly. I’m absolutely not averse to seeing it progress, but we don’t have resources at this end for it.

My personal take on this thread, I’m afraid, is that RISC OS has far more pressing things that need developer time, as covered by a myriad of other threads. But, as others have said, if someone wants to take up the mantle, then more power to them.

PS, the reason for several versions of SecureSockets module is that we found 32bit neutral versions wouldn’t work on OS3.70 and earlier, so we had to keep several versions alive for older systems. These days, I doubt that would be worth consideration.

Deprecating dangerous SWIs is pointless when a user privilidge program can add anymore they like with a simple rmload.

Changing RISC OS to not allow users to load modules is left as exercise to the reader.

The only feasible way to do this is to run every app in its own virtual machine, along with some probably sophisticated IPC firewalling. This is a lot of work, as RISC OS assumes a single level of trust. For example, any WIMP task can scribble over any other WIMP task’s memory, without even using module or SVC code.

As for SSL, a RISC OS module for SSL is probably only of use for software written in Basic. Every doing native code work (C, C++, Ada, etc) should be using libssl directly.

On a side note, I wonder if anybody has considered doing a libffi for talking to ELF shared objects on RISC OS from Basic. That could murder several avians in a single shot.

Every doing native code work (C, C++, Ada, etc) should be using libssl directly.

Not easy to use from Norcroft C (that’s why many projects, as HTTServ, do not use it).

Changing RISC OS to not allow users to load modules is left as exercise to the reader.

Trap Service_ModulePreInit?
That said, RISC OS without the ability to load modules. Doesn’t that kill something of fundamental importance?

That said, RISC OS without the ability to load modules. Doesn’t that kill something of fundamental importance?

RISC OS without the ability for users to load modules outside of a specific configuration utility designed to produce an authorised list?
There you go, broke the ability of users to break the OS with random modules.

RISC OS without the ability for users to load modules outside of a specific configuration utility designed to produce an authorised list?
There you go, broke the ability of users to break the OS with random modules.

I’m just wondering how many software products make use of modules? Quite a number of mine do. I’m wondering who would administer this acceptable modules list, and if it does anything remotely smart like CRCing the module data to uniquely identify a specific module (instead of any old crap called <allowed module name here>) then exactly what is going to happen if and when modules are updated? Let’s say UnixLib or Tinct is whitelisted and it is updated, then what?
Would this also not be a huge barrier to software development (bordering on possible antitrust) if a developer needs to get his/her module(s) whitelisted and get everybody’s lists updated before the OS will even attempt to load the module?

The problem is modules run at kernel level and there are legitimate user apps that contain modules; for all sorts of reasons, but a primary one being the OS design cannot cope with vectors/servicecalls/events in apps that are paged out – you either have the OS jumping in to random parts of other tasks, or you delink everything and risk missing the message, neither option is satisfactory. A small module can “fix that” and report status using poll words. There are many other possibilities, but the ability to be able to load modules is, you know, kind of important to how RISC OS itself functions.

While it might sound like a neat idea, I can see it blowing up in all sorts of unpleasant ways.

(Not easy to use from Norcroft C (that’s why many projects, as HTTServ, do not use it).)

This sounds like a reason to not use Norcroft C. Especially as using Norcroft means building on a slow computer with inferior tools.

While it might sound like a neat idea, I can see it blowing up in all sorts of unpleasant ways.

Another way, with fs-lock, could be to avoid code launching from public directories. So no code loaded without authorisation.

This sounds like a reason to not use Norcroft C. Especially as using Norcroft means building on a slow computer with inferior tools.

For me, it’s not, since I only have a RISC OS computer at home :) BTW, other people will say that it is a reason not to use libssl.

“but the ability to be able to load modules is, you know, kind of important to how RISC OS itself functions.”

Yes, this is not changing anytime ever, it would break most applications that still happen to be maintained. As such deprecating ‘dangerous swis’ is pointless and would just lead to application breakage for no gain.

There are two choices

1) Make ‘RISC OS’ secure, massively change the way that the OS works, taking thousands of man hours, breaking nearly every app in the process and at the end have something that isn’t ‘RISC OS’.

2) Live with the fact that RISC OS fundamentally isn’t secure, and that malware is trivial to write for it. Give up on this bounty as the money would best be spent elsewhere.

I can only see 2) as the likely outcome.

It seems to me that there is a question of whether SSL would be a useful thing to add to RISC OS in an open and up to date way. There are several aspects to security. Being able to do banking on RISC OS without leaking information is something I’d have thought was useful. It’s a different aspect of security from keeping hackers out of your computer.

Dave, NetSurf has a (nearly) very latest OpenSSL, with SSL actually disabled (too many security problems), exclusively TLS. This probably makes its cryptography as good as any browser on any platform.

The NetSurf project provide pre-built toolchains complete with environment of loads of useful libraries (including OpenSSL) to aid developers working on NetSurf; they can probably be used by other people for other things too. With GCCSDK and our toolchain patches, OpenSSL basically builds out-of-the-box.

Sadly NetSurf, along with most RISC OS programs, ship statically-linked. Meaning that each application must be updated individually when a security problem is found (rather than just updating one shared object.)

This is why I suggested that perhaps we should have a concerted effort to move to ELF/shared objects, and provide an FFI library for people who insist on using BBC Basic.

The only question is if the people who want to stick with Norcroft will be able to interact with that.

So it can’t be provided as a module that any client(s) can call?

Sorry if I’ve failed to understand earlier posts.

And I probably mean TLS really.

is why I suggested that perhaps we should have a concerted effort to move to ELF/shared objects

Why not simply a module? (as an independent project, of course).

Peter:

1) Make ‘RISC OS’ secure, massively change the way that the OS works, taking thousands of man hours, breaking nearly every app in the process and at the end have something that isn’t ‘RISC OS’.

The only way this could stand to work is if the kernel and important system modules retained SVC mode, and everything else was kicked down to SYS mode, so it could access more privileged areas without messing in kernel space. This would imply a shadow RMA, but hey, that’s a piece of cake compared to breaking every module ever written. ;-)
Oh yeah, and it would obsolete anything that doesn’t have SYS mode – uh, which might even be the Iyonix?!

Rob:

This is why I suggested that perhaps we should have a concerted effort to move to ELF/shared objects,

Really? And, pray tell, what does a (non-native) ELF offer that can’t be offered by a module?

and provide an FFI library for people who insist on using BBC Basic.

Who insist on using… the wording says it all, doesn’t it?

All:

I have looked back at the original post. 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.
I think we are going to have to accept that the system is fundamentally insecure and that it is probably next to impossible to “fix” that without breaking most of what we like about RISC OS. I use “fix” in scare quotes because if you look at other platforms (read El Reg, etc) you’ll see that security on popular platforms is a constant game of whack-a-mole and patches and updates. Given that development is already slow due to a lack of people and hours in the day, who would take on such a task?

Maybe it might be better to look instead at alternative interpretations of this request… To compile a list of known issues that are not otherwise documented (like “hey, if I pass -1 to this Wimp SWI, everything dies horribly!”¹) so that we can work towards making the system more “secure”, not by way of keeping nefarious twats out, but by making it more robust and less likely to break on dodgy input or programmers doing unexpected/idiotic things (like this!).

¹ Made up…I hope. ;-)

Why not a module? Because modules don’t use the C ABI. Which means a lot of work to make the code safe to run as a module/in supervisor mode, and designing and implementing a whole new API to wrap the original one.

Use a shared object → thousands of off-the-shelf libraries become available to be shared between applications very rapidly. Using “kernel modules” as shared libraries is an insane hack that was only used because we didn’t have shared objects yet. Now we do.

Really, the problem is that to truly fix RISC OS security, your options are either to take a decade to deprecate things (the end result would look very different from today’s RISC OS), or just throw money at the ROLF project or something.

aaa