Bounty Proposal: Increase RISC OS Security

Already there is the !store system

Oh, now that is hilarious, citing !Store as a way to improve platform security. (An exercise for the reader: Buy something from !Store while monitoring the traffic with Wireshark. I’d recommend bogus credit card data, myself. Please note the complete and utter lack of asymmetric cryptography. Also, when you give them bogus credit card data, note that it may take hours to be rejected, which means that they are storing it, directly contrary to what !Store says about that.)

It’s not trojan horses that you have to worry about, this is RISC OS, there are four of you to be attacked by a trojan. It’s vulnerabilities in the legitimate software you’re running, it’s insecure protocols that allow your traffic to be sniffed (!Store is a perfect example) or easily hijacked (again, !Store is a perfect example), that kind of thing.

Really, !Store is a perfect example of the lack of security culture in RISC OS, and why outdated commercial RISC OS dev tools (that make it hard to be secure) suck.

GCC does support shared libraries, using the standard ELF format. The system works now, and is proven, so it’s hard to see why it’s a problem unless you’re adopting a “not invented here” approach to progressing the platform.

No. It’s just not available in standard RISC OS 5 distribution.

And not very efficient too. In one of my project, I make dynamic malloc at runtime. GCC under RISC OS is the only compiler that generate code that crashes my computer. Works well on a PC. On Acorn C too. Problems are not always on the DDE side. Tu put a sticker GCC or ELF is not enough. What about efficiency on ARM, interaction with modules, possibility to mix ARM26/ARM32 code, code compression (would help with disc I/O problems), code signature (would help with security), etc.?

Of course, since it’s available, it could be a good solution. Needs checking and some study on benefits and problems. That’s my point. To say it’s available and well known so we MUST use it, is not my way to work. Windows DLL are too, and they are now a big failure.

aaaa

For me the biggest potential problem of security i see with riscos is lack of documentation on applications/modules etc

I think that some modules (etc) are helpers to get a job done and are not intended for third party use.
Consider my MoreKeys. The documentation says generally how it works but it doesn’t go into detail. You use the application or you don’t…

If it’s advertised as ‘disc utility’ and it format the hard drive, they you’ll say ‘crap, this system lack security’.

No, I’d say one of:

• Piece of crap program should have warned me it was going to do this.

Or:

• Should have read the user guide, dumbass!

why outdated commercial RISC OS dev tools (that make it hard to be secure) suck.

? Why is it the compiler’s fault that the security of an application sucks?

aaaa

It’s the compiler’s fault if it makes it difficult to follow best security practices, when another compiler does not make it difficult.

Also, it’s advertised as not storing your credit card info anywhere other than your computer, which is definitely wrong. And, if you’re handling payment card info, you’re required to follow the PCI DSS standards, and I’d be surprised if R-Comp’s encryption meets requirement 4 (especially considering that they’re hinting that even TLS 1.0 doesn’t meet it, as of the PCI DSS v3.0 docs).

aaaa

You are not required to follow the PCI DSS standards, but if you don’t you may get either hammered with huge costs or refused by your merchant bank to trade.
Given the fact they are processing card data, the whole !Store process will have been vetted by a third party PCI auditing company to ensure compliance. !Store will have to be PCI DSS v3 compliant when it is next audited.
!Store doesn’t need to store the card details anywhere other than at the computer end – and if you don’t save them they won’t even be stored there.
If it’s a credit card you don’t need to store details of the card to process it, you can get a third party (Whether that’s a bank or something like paypal) to store it for you and use a reference number to re-auth the card – dependant on the API provided of course. Which is great as you don’t need to store card details that way.

I don’t know anything about !Store, but I’m not sure why you are saying it’s “definitely wrong”, unless you’ve got access to the server side code – which I don’t.

OK, they may have someone else storing the data, point there. But, that does mean the data is being stored SOMEWHERE other than your machine, making at least one statement inside !Store false.

But, well, this is a raw packet from the thing: http://bhtooefr.org/files/PlingStorePacket.txt

The card data in that packet is COMPLETELY bogus, so I’m not revealing anything sensitive by posting that.

I’ve also got a good guess as to what the secret that that was encrypted with was, from running strings on the unsquashed binary. (Cryptography isn’t something I’m skilled with, though, so I haven’t figured out how it’s actually encrypted yet. It’s obviously in Base64 right now, but the only thing that’s human readable after decoding it is my username backwards.)

That packet was sent in the clear though, and I doubt that R-Comp was using any particularly good encryption. I would be quite surprised if that passed a “strong encryption” test.

Oh, now that is hilarious, citing !Store as a way to improve platform security. (An exercise for the reader: Buy something from !Store while monitoring the traffic with Wireshark. I’d recommend bogus credit card data, myself. Please note the complete and utter lack of asymmetric cryptography.

What did R-Comp say when you discussed this issue with them?

Also, when you give them bogus credit card data, note that it may take hours to be rejected, which means that they are storing it, directly contrary to what !Store says about that.)

I’d assumed that meant that the details were only stored for long enough to process the transaction (which could be done manually on a terminal when someone gets time to process your order/checks stock availability, not automatically), not that the details were not stored at all. If the receiving server didn’t store your details at all, even for long enough for the transaction to process, then there’s no point in sending them.

Given the fact they are processing card data, the whole !Store process will have been vetted by a third party PCI auditing company to ensure compliance. !Store will have to be PCI DSS v3 compliant when it is next audited.

Will it? If Eric’s right in his guess that !Store is just delivering the card info to someone’s computer for them to manually put through an offline terminal, would the merchant bank even need to be aware that !Store existed? Note that’s not should they be aware, but would they necessarily find out if they weren’t told about it for whatever reason?

And not very efficient too. In one of my project, I make dynamic malloc at runtime.

I’m not sure that has much to do with dynamically linked libraries?

GCC under RISC OS is the only compiler that generate code that crashes my computer. Works well on a PC. On Acorn C too. Problems are not always on the DDE side.

Was your code OK? It’s quite possible to write buggy code (eg. buffer overruns, assumptions about pointer validity, etc) that just about works on some settings of some compilers and breaks on others. I’ve written duff code that works fine on GCC -O2 but fails spectacularly when -O3 is applied, for example.

Something small I wrote the other day worked fine when compiled with GCC but crashed the machine when compiled in Norcroft. Unsurprisingly, when I looked closer, my code was buggy.

Tu put a sticker GCC or ELF is not enough. What about efficiency on ARM

I believe that GCC is now regarded as generating fairly good code (whereas it once wasn’t).

interaction with modules,

GCC can do modules, AFAIK.

code compression (would help with disc I/O problems),

NetSurf’s binaries are squashed these days, for just that reason. That’s done on the Linux build machine.

I’m not sure that has much to do with dynamically linked libraries?

No. That was an introduction for this: “problems are not always on the DDE side. Tu put a sticker GCC or ELF is not enough.”

Anyway, this thread is not really about shared library either.

Was your code OK? It’s quite possible to write buggy code (eg. buffer overruns, assumptions about pointer validity, etc) that just about works on some settings of some compilers and breaks on others.

Here is an example. Pure ANSI C.

char **ElementsInFile = NULL;
ElementsInFile = malloc(sizeof(char) * 10000);
for (x = 0; x !=10000; x++)
{
ElementsInFile[x] = malloc(256 * sizeof(char));
}

Works in Windows with TCC & GCC. Works on Linux with GCC. Works on RISC OS with Acorn C. Works with GCC on RISC OS too.

Now if I make this:

char **PoolString = NULL;
PoolString = malloc(sizeof(char *) * (atoi(ElementsInFile[limit+1])));
y = atoi(ElementsInFile[limit+1]);

for (x = 0; x !=y; x++)
{
PoolString[x] = malloc(256 * sizeof(char));
}

So a malloc with size defined at runtime (one more time, it’s pure ANSI C). It works on all the above compilers, but GCC 4 on RISC OS. I check asm code, and I suspect the use of static size defined at compilation for the size of the malloc (or something closed).

I believe that GCC is now regarded as generating fairly good code (whereas it once wasn’t).

Yes, it is. But ‘is now regarded’ is not enough for me :)

GCC can do modules, AFAIK.

Hum, I was talking of the shared library system. If it doesn’t interact with other RISC OS mechanisms, or if it do not provide features that could help RISC OS becoming better (signed code, multiple versions of code [softfloat+hardfloat in same binary], compression, etc.), it’ll just be inadequate.

NetSurf’s binaries are squashed these days, for just that reason.

Cool. But is this feature managed by the elf container, or the application itself?

Damned: TCC does not work under Win64. It seems to link 32bit code to 64 bit libs. It’s really time for me to go back to RISC OS :)

Yeah well, it’s lot about program advertising what they are doing, what they are accessing , what function they expose, and in what kind of setting you may want to have them installed or not.

I think you’ll find quite a lot of traditional programs do not mention this sort of stuff. Case in point – SMPlayer(MPlayer) and VLC. They play videos. Lots of info on video playback methods. In order to be fast I would reckon there’s some fairly low level stuff going on somewhere in there. Both can also stream off the internet. Is that their only access? It won’t ever send system statistics like a list of installed programs and your Microsoft licence keys? How do you know? How could you tell? The best we can do is get our stuff from reputable sources and trust that the developers won’t try something slimy like that.

You have a more cohesive permissions system on mobile devices (iOS and Android for example), but this is often worked around by being a trojan and tricking hapless users into giving too many rights to a bad program. Or just totally lying about what you want and what you need it for. So even with some sort of security, it is not much good if it isn’t an important thing in the user’s mind.

how much of a security issue would it be to know if this is supposd to be ok to install this on the machine or not etc

The answer is, obviously, not. As in, do NOT install it.
The only way you can be sure is to either examine the source code (assuming it was available) or to conduct a code analysis. You can’t trust me, you’ve never even met me. If I wanted to pirate all your software by zipping it in the background and pushing it to a torrent host, of course I would neglect to mention that, don’t you think? So, whatever I say, would you be able to trust me in a secure environment? Answer? No. Just as I would not be able to trust you or your code.

But, RISC OS is not even remotely secure, so there’s no problem then. ;-)

wordpress etc, if you start to install non trusted modules, or mess up too much with it, there is always a point where the security will decrease too

Yes: http://www.theregister.co.uk/2015/02/26/plugin_puts_a_million_word_press_sites_at_risk_of_compromise/
Yes: http://www.theregister.co.uk/2015/02/06/fancybox_clops_zero_day_affecting_thousands/
Yes: http://www.theregister.co.uk/2014/11/24/worst_wordpress_hole_for_five_years_affects_86_of_sites/

But, sometimes the tools are faulty:
http://www.theregister.co.uk/2014/10/01/researcher_details_nasty_xss_flaw_in_popular_web_editor/

And sometimes the service itself is faulty:
http://www.theregister.co.uk/2015/03/20/facebook_leaking_private_photos_vuln/
http://www.theregister.co.uk/2014/08/31/jlaw_upton_caught_in_celeb_nude_pics_hack/

And sometimes it is just really dubious stuff:
http://www.theregister.co.uk/2014/10/27/icloud_data_grab_irks_privacy_conscious/
http://www.theregister.co.uk/2015/03/12/consumer_group_petitions_mattel_to_pull_wifi_enabled_barbie/ (ugh…)
http://www.theregister.co.uk/2015/02/09/samsung_listens_in_to_everything_you_say_to_your_smart_tellie/

If you let user being able to install drivers, and they install bad drivers, no security system in the world will make the box secure.

The best security is quite easy: Unplug the internet and only run software you believe you can trust.
Problem is, many people (Yours Truly included) are too tethered to be able to unplug.
Then you get that special sort of person that insists on installing everything from everywhere and then cries when it all goes horribly wrong.

but lot of hashes, crc, pgp keys etc to verify packet integrity,

That’s possibly the only thing that prevented malware-modified versions of Linux. http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/ The site kernel.org was hacked (in 2011), the intruders gained root access, passwords, and so on, but it looks like the files themselves were not compromised; though I wonder if somebody somewhere isn’t trying to come up with a way to try to make it work…?

But. All those keys and hashes fail to assure security. They only assure that what you downloaded is what the originator of the file put on the site. It says “yes, this is the same file” not whether or not the file is any good. Again, we’re back to the question of trusting… well… trusting trust itself, I guess.

The best is to use Android. Perfectly secured OS, with 98% of applications that steal your personal data. And nobody cares.

I’d assumed that meant that the details were only stored for long enough to process the transaction (which could be done manually on a terminal when someone gets time to process your order/checks stock availability, not automatically), not that the details were not stored at all.

Quote: All information will be stored and submitted in an encrypted format, and is stored only on this computer, not on the server or anywhere else.

It says quite clearly not on the server or anywhere else. Obviously this is wrong, for two reasons. Firstly it has been observed that there can be a delay in processing the data, and also – as you point out – to not provide the data somewhere would render it somewhat useless.
However, as a processor of credit card information, one should be aware of the potential problems of asking for the cardholder name, card number, expiry date and the CVC. This is all of the information necessary to make a purchase with a card.¹
As such: Where is this information going? Where is it held? Has this process been audited (I mean, it isn’t emailed in plaintext it to a shop mail address is it?)? What is the privacy policy regarding retention of this data? Who assures that this policy is followed? When is the data erased? Can it be proven to be erased? Has this been audited? Are printouts of the card data ever made? Sure? (if so, how are they disposed of?)

There is a reason people like using PayPal for receiving payments. Safely handling credit card information is not such an easy task.

would the merchant bank even need to be aware that !Store existed?

If there was a suspicion of fraud, the card processor and/or the bank would potentially want to examine the entire transaction chain to see where any faults may have arisen (and, of course, to shift the blame/liability somewhere else).

Description of the PCI DSS → http://www.theukcardsassociation.org.uk/security/what_is_PCI%20DSS.asp
It might need some custom software if working with RISC OS, but otherwise it doesn’t look to be that difficult. Primarily making sure that only people that need access to data have access. It doesn’t mention data expiry though, which is disappointing but not unexpected.
I like that the monthly non-compliance fee is £9.99. That’s an even lighter slap on the wrist than the ones OFCOM delivers!

¹ Which is why my bank would follow that up with an SMS saying who wants paid, how much, and a unique code to enter into a form to authorise the payment – and a window of 180 seconds in which to do it. If !Store can’t support that (ha ha, as if!) then I’m afraid my card just won’t work to buy stuff in a “customer not present” sense…

Perfectly secured OS,

No such thing.

with 98% of applications that steal your personal data.

I wouldn’t know. If an app shows itself as wanting any weird permissions, it doesn’t get installed. I did come across a “turn on the LED to be a torch” app that wanted to access contacts and SMSs. Some fifty thousand bleating sheep had installed it. I wasn’t one of them.

And nobody cares.

“The Apathy is strong in this one”

Yeah. Too many people don’t realise, and too many people already post their private stuff to Facebook so probably won’t care.

My mother has a penfriend who works in a government place. I recently saw the names and email addresses of dozens of co workers, and also some of their private email addresses (same name, non-gov email). How? Simple, the instruction given to the machine was surely “send this generic (pointless) wow look at this email to EVERYBODY in my address book in such a way that everybody’s addresses can be seen by everybody else”.
Duh.

Security 101! Use To: and CC: for close friends that know each other. To spam an entire address book… just don’t. But if you really must (no, you are mistaken, you don’t need to!), either use software that will sent individual messages or send it to yourself and add the world to the BCC line.

The bank stores your card data, I would assume RComp didn’t mention that as it is assumed that most people would figure that one out.
Unless you are assuming they do not, which would make it rather hard to authorise a transaction now wouldn’t it.
It’s perfectly valid, secure and I would say more efficient to only encrypt data that needs to be done.
That is the main benefit of TLS over SSL, you can switch it on and off at will.
The fact that it is in Base64 doesn’t mean anything at all, that is probably done to make it easy and efficient to extract the encrypted string.
My guess (and it is only a guess) is that the string is pushed through one of the ciphers that SSL/TLS supports that are PCI compliant.
Also remember that some of the ciphers that are in SSL are in TLS, also that using SSL v3 with some of the ciphers is insecure, whereas using the same cipher in TLS is OK.
If you can crack the cipher then I would show RComp how you did it and get him to fix it as an urgent issue, which I’m sure he will.
Finally, if you are aware of the way transactions work – which you may not be, they are two phase:
1) Real time authorisation – this transmits an authorisation code to the merchant (i.e. RCOMP), the money is then locked in your account.
2) Settlement – at night the transactions are added up and the money is actually taken from your account.

So what you can do is authorise a transaction, then decide whether to release the transaction for payment or to alter the payment (usually send a request to invalidate the auth so the payment doesn’t take place, or an immediate refund if you can’t invalidate the transaction)

If you’re really interested there are a bunch of standards you should read
Real old school formats too! Kind of funny to see it!
If you want an overview of the way payments for merchants please read this

And finally yes they would be aware that !Store existed, you have to declare it AFAIK.
!Store will have been pen tested by the auditors, I’ve used those auditors at multiple companies and I’ve always been surprised what they managed to dig up with mobile applications and how thorough they are.
They were probably fighting to pen test it! Given it’s so different, not the usual iOS/Android crap.
Whether it’s processed through a terminal, or through an API makes no difference.
!Store effectively becomes a terminal, thus comes under PCI regulations.
When you say it takes hours to be rejected, that’s rejected by RComp NOT by the bank.
Again this goes back to the transaction pipeline, authorise THEN settle.
You can manually check transactions – which given there is no 3DSecure (or Verified by Visa etc.) in !Store, would be the ONLY way I would recommend any process it.
Which can’t be done easily unless there is good SSL/TLS support AND javascript support in a web browser on RISC OS.
So RComp are from my limited perspective (chuckle) doing this in 100% the right way and the pause is likely there to protect both RComp and the consumer from fraud.

Of course if you can hack the encryption on the card details field, then you may have something.
This is far from complete and there is tons of detail missing from this post, but if you want to learn more it’s really interesting.
Then of course there is how the ATM/chip encryption works, that’s really interesting.

GCC can do modules, AFAIK.

Hum, I was talking of the shared library system. If it doesn’t interact with other RISC OS mechanisms, or if it do not provide features that could help RISC OS becoming better (signed code, multiple versions of code [softfloat+hardfloat in same binary], compression, etc.), it’ll just be inadequate.

I think the Linux thing is to build the software so it is tuned for your particular machine

Yep, but elf can also contain different binaries in the same package (an almost hidden feature :) ).

ps. Why does !Netsurf sometimes display ROOL forum double the page width? :-)

Because there is something on the page that is wider than normal.

In the case of this discussion, it’s the raw packet of !Store data that Eric quoted; it’s a single unbroken line (no spaces) which is rather long.

Edited my post to make that packet a link, I had checked in the browsers immediately available to me at the time of the post (none of which were NetSurf), and while some horizontal scrolling was required to read that line, the page wasn’t broken.

In any case, I didn’t see any signs whatsoever of asymmetric (public key) crypto when I was sniffing the traffic. Cryptography isn’t my forte, so I probably won’t get it broken, but I do think that R-Comp should probably consider building OpenSSL or another maintained SSL library into !Store, and connecting to their server over TLS (and, seeing as they could build against the very latest OpenSSL, and only !Store is connecting to their services and is auto-updated upon launch, they could aggressively deprecate insecure protocol/cipher combinations) at the very least.