back to article Linux is part of the IoT security problem, dev tells Linux conference

The Mirai botnet? Just the “tip of the iceberg” is how security bods at this week's linux.conf.au see the Internet of Things. Presenting to the Security and Privacy miniconf at linux.conf.au, embedded systems developer and consultant Christopher Biggs pointed out that Mirai's focus on building a big DDoS cannon drew attention …

Silver badge

No, the enemy is the idiot who wrote the specs

If you look at the "standard" specs for IoT protocols, such as ONVIF they cannot be implemented on a small system with minimal attack surface. The spec requires a fully blown SOAP implementation, RTSP implementation, HTTP implementation and god knows what else. The Internet facing attack surface is gigantic by design.

This is just the standard - before we add all the backdoors for illegal (as they violate the DPA) luser friendly applications which report all of the activities in your house to a server in Shenzen so that a similarly insecure android app works in order for the customer to spy on his household.

This "insecure by design" spec + extra "market requirements" is then given to be implemented by "Joe Embedded Developer" who never had to write any secure code in his entire career.

The results are as expected and should be fixed at the root. Just take all authors of the ONVIF spec and march them off the plank somewhere in the middle of the China Sea. The local flora and fauna will do the rest (*).

(*) There is no need to march the marketing which spec-ed the android app reporting you to a server in Shenzen. That can and should be dealt with by enforcing import laws. Any piece of kit running this software is illegal and should be diverted straight to recycling at customs.

25
1
Silver badge

Yes, but that's actually a general trend

We see more and more idiotic standards around. With the availabilities of libraries for just about any usecase, it seems trivial to just cram them together instead of making your own lean and simple purpose built protocol.

As with most security problems, it's probably caused my immature programmers. Every programmer has an urge to build complex "castles in the sky". Mature programmers have learned to control that urge and funnel it into creating simple but flexible systems.

In a way one could say that using Linux for systems which could work with some much smaller RTOS is a problem, particularly when you run additional services on it, but any decently mature developer will try to avoid having such unneeded services in favour of a serial port on a pin header on the board.

13
1
Silver badge

Re: No, the enemy is the idiot who wrote the specs

SOAP, RTSP and HTTP don't need Linux. How about QNX? VxWorks?

The real problem is money. The market for small things like this is ultra-competitive, and if you can save a few cents per unit in manufacturing then that's what you do.

Linux has no license costs. In large numbers, an alternative OS might be licensed down in the cents/unit area, but that still a large amount of money out the door.

And as for the idea of keeping a dev team stood up purely to provide support for products in the field, no way is that cheap or profitable (at least not in the short-sighted eyes of the company accountants...), and certainly not if one has gone and spun up a customised stripped down distro that one now has to maintain oneself.

[An exception is, apparently, Belkin, who do at least respond to vulnerability reports and issue updates. Shame their Android app, through which the update process is managed, is awful at doing the update itself. The iOS one is much better].

And clearly the market simply does not give a damn about bugs, vulnerabilities or malware in these things. Some botnet running out of one's own house probably does not impact on the owners of the house in any noticeable way. The only exception I heard of was Nests in the early days - too many bitcoin miners infesting one's Nest meant that it actually stopped working as a thermostat.

Regulation

Faced with a situation where the customers for IoT devices don't know, don't really care, couldn't do much about it even if the did know that their thing was up to no good, how does the behaviour of the market get changed to prevent all this becoming a truly dangerous thing to the Internet (an thence the economy) as a whole?

The only option left is regulation imposed by government. They're the only outfit that can forcibly change the market's dynamic when the market itself shows absolutely no sign whatsoever of sorting itself out. Though exactly how that's done without mandating an OS + distro, encryption standards, etc. that doesn't make it massively expensive thus killing the market and a massive target for blackhats looking for the thrill at getting one over on the government, I've no idea. Perhaps forcing adoption of HomeKit and maybe a couple of others isn't such a bad idea.

9
0
Silver badge

Re: No, the enemy is the idiot who wrote the specs

It is not Linux which is the problem. The alternative OS is likely to either use the same horrid, buggy and insecure SOAP, RTSP and HTTP off-the-shelf code or even worse - the developers rolling their own.

The regulation is already there - I have so far tested only one legal IP CCTV camera. Funnily enough it had an instruction in German. All the other ones were violating DPA and other Eu privacy and data processing related directives, thus making them illegal to be sold.

The problem is that the toothless corporate arse licker known as DPA in the UK will never ever go as far as prohibiting an item for import for violating the regs. Most other countries are not much better.

18
0
Silver badge

Re: No, the enemy is the idiot who wrote the specs

Problems often arise in the name of security itself. See a well-known tickbox risk, fix it by creating more complexity and a bigger - but unknown - risk. Security tickbox ticked.

Reg readers will not be unfamiliar with entirely-predictable consequences. I'm reminded of http://www.theregister.co.uk/2007/08/24/everything_over_http/ (from when I had an Apache column in a branch of this publication).

4
0
Silver badge

Re: No, the enemy is the idiot who wrote the specs

"is then given to be implemented by "Joe Embedded Developer" who never had to write any secure code in his entire career."

I'd sooner trust Joe Embedded Developer who will have at least some clue about programming, than Wally Web Developer who thinks that HTML is programming and Javascript is the square peg that fits into any round hole and also sorts security issues by getting his dogs dinner code to pull in and use the l337security.js module from yoocantrustus.honest.guv.cn

13
0
Silver badge

Re: No, the enemy is the idiot who wrote the specs

I'd sooner trust Joe Embedded Developer

You have the worst of those worlds in this area as ONVIF and Co are web based specs - soap over HTTP. So you have both embedded developers doing customer facing http work and Wally Web Developer doing system configuration. With the results expected from either.

8
0
Silver badge

Not dumb enough

There are three key parts to the Internet of Shyte problem:

(1) Many IoS devices, and ideas for devices, really are just solutions looking for problems. Nobody needs an IoS kettle or lightbulb, not really. Every oven already has a delay start timer. Thermostats with timers have worked fine for 100 years. The marketurds have gone wild trying to sell unnecessary crap.

(2) Even the useful devices become too vulnerable by being too smart. It is NOT necessary for a CCTV camera to host a complex *ix OS. Basic CCTV systems have been working securely and stupidly for six decades.

(3) Governments, dumb as ever, have failed their duty by not understanding the problem and then regulating for it. We should already have regulation for IoS devices controlling security, software quality, privacy, and penalties for unfit products, just as we do for electric blankets, medicines and food.

20
2
Silver badge

Re: Not dumb enough

>(1) Many IoS devices, and ideas for devices, really are just solutions looking for problems. Nobody needs an IoS kettle or lightbulb, not really.

Many people don't, but in countries with ageing populations there will be some scope for home automation. If people can't make something as simple as a lightbulb secure, then we should be very worried about more complex systems in banking, food production, power generation, remote health monitoring etc.

I agree though that many products on the market are shite, and are being sold for their own sake. However, it is a very immature market, and the average Joe hasn't rushed out to fill their house with IoT stuff. The billionaire Joe has had home automation products available for years, though usually wired into the walls.

What is encouraging is that an awareness of how insecure today's IoT offerings are has reached the mass media (Radio 4, at least), so perhaps there is scope for security to be improved through market forces?

0
0
Silver badge

Re: Be worried? What, me worry?

"If people can't make something as simple as a lightbulb secure, then we should be very worried about more complex systems in banking, food production, power generation, remote health monitoring etc."

Point taken, Dave, but when have we ever heard of a hospital or a bank being hacked? [/sarcasm]

Yes, well, so we are already worried about those more complex systems, because we haven't been able to keep them safe either. Neither by regulatory legerdemain nor by mysterious market "forces".

Those mysterious market forces have, I think, turned out to have less to do with market perfecting itself through competition and more to do with the market creating consumer demand for relatively useless products. Adam Smith's invisible hand is actually the use of propaganda, both obvious and subtle, convincing consumers to buy stuff -- IoT -- that they don't need. And which the market manufactures as cheaply as possible, which practically mandates that IoT will have vulnerabilities you could drive Fancy Bear through.

5
0
Silver badge

Re: Be worried? What, me worry?

>more to do with the market creating consumer demand for relatively useless products.

I think they have failed at creating a market demand because: I'm seeing any demand for the current generation of of IoT gear. And I don't think think that we see demand for it until it is not shit.

It's like smartphones - most people stuck to their old Nokias until Android and Apple were good enough... it took a few years before the advantages of a capacitive touchscreen phone made up for its disadvantages (price, battery etc) for the average user.

The first generation of MP3 players weren't a good choice compared to MiniDisc. Energy-saving lightbulbs were shit (CFL) and now they are good (LED). The internet and later WWW was around for a long time before Joe Average bothered with it. Digital cameras... well, you know it.

(PS, that's a curious definition of the Invisible Hand you have there! Have a read up on Complex Adaptive Systems - the concept is that the 'invisible hand' is an emergent phenomenon, not a deliberate one. It is true that companies set up t produce gear that we are no longer buying will try to sell us new stuff we don't need, but that isn't what the invisible hand refers to! :))

3
0
Silver badge

Re: Not dumb enough

Even the useful devices become too vulnerable by being too smart. It is NOT necessary for a CCTV camera to host a complex *ix OS. Basic CCTV systems have been working securely and stupidly for six decades.

Yes and no. The *ix OS comes courtesy of image analysis. Basic (emphasis on basic) CCTV systems cannot cope with image analysis at the rates generated by modern cameras. Try feeding 10 H264 HD streams into let's say motion even on a fairly hefty CPU and watch the show.

While you can (in theory) implement all the relevant image analysis _AND_ alert actions based on image analysis on a non-*ix OS, it is not worth it. You are likely to end up with something broken and insecure in a different way (f.e. hackable via its alert submission channel). The idea of moving to IPoE + image analysis on the cameras is actually sound. So is the idea of using general purpose OS on the Arm SoC which is running the camera in order to run the analysis there. The overall cost of Cat6 + cameras + DVR/Alert management + power is already half the cost of a comparable "basic CCTV" system and dropping further.

The control protocol however (ONVIF) and the implementations of said control protocol in the field are complete and utter sh*te. The people who came up with it deserve to be subjected to some form of cruel and unusual punishment.

3
0
Silver badge

Re: Not dumb enough

(1) I've always struggled with what exactly you put in an oven on delayed start that won't start to go a little bit rank before the oven comes on, especially in climates such as Australia. Garlic bread maybe?

(3) I'm not sure whether to attribute lack of Government action to malice (more data and attack surfaces, especially CCTV feeds) or simple incompetence.

The whole IoT nonsense seems to be driven by the "everything on my phone right now" brigade that unfortunately couldn't, in general, secure their own network in the least at are likely just unknowing botnet participants. The minimum is "no external contact, and I'll VPN in thank you very much".

Same with air conditioners. Guy at work is getting a new ducted system that "I'll be able to switch on to cool the house while I'm at work". That really makes the assumption that:

1. You've shut the house up when you left in which case why not have the system running all day on a low power setting, or

2. You don't mind huge bills as all that cold air pisses out of the windows.

Personally I wouldn't trusted an air-con company to construct a secure external facing API and I certainly can't imagine the fitters setting up a firewalled network with VPN access.

1
0
Silver badge

Rolling your own vs. getting Linux

It's always easier and cheaper to stick Linux on an IoT thing, just like it's always easier and cheaper to slap Android on a mobile. That will only change when someone comes up with another IoT OS that's easier to develop for than Linux... and makes it free, of course.

4
1
Silver badge

Re: Rolling your own vs. getting Linux

Well, let's get coding.

The OS is less of a problem than device drivers...

But they could be linux compatible.

0
1
Silver badge
Linux

Re: Rolling your own vs. getting Linux

Instead of starting your own kernel, try Linux "make menuconfig" sometime. Most of the features in the kernel can be turned off. By enabling only what your application needs, you save memory greatly, and reduce the attack surface.

11
0
Silver badge

Re: Rolling your own vs. getting Linux

Though good luck convincing some people to do it, you get excuses about how it's not worth doing because it saves hardly any space, or it doesn't matter because component x isn't active (ignoring possibility of nefarious activation), never mind having to fight against the 'install everything' mentality which was far too common even back when disk space wasn't cheap.

And the comments about the mental amount of overhead software just to implement the basic 'standard protocol' stuff are thoroughly depressing. Clearly not designed by people who comprehend how things are actually made to work.

3
0
Anonymous Coward

Re: Rolling your own vs. getting Linux

"By enabling only what your application needs, you save memory greatly, and reduce the attack surface."

And you may end up running a relatively unique system configuration, which has advantages and disadvantages.

2
0
Silver badge

Re: Rolling your own vs. getting Linux

>That will only change when someone comes up with another IoT OS that's easier to develop for than Linux... and makes it free, of course.

It seems to be a wasted opportunity for Blackberry.... not only do they own QNX (which has a footprint a tenth the size of Linux, and is an RTOS of long standing in industrial control systems) but also Blackberry themselves have a good reputation for security amongst the public. Oh well.

5
0
Silver badge

Re: Rolling your own vs. getting Linux

Trouble is QNX ain't free, making it a non-starter.

1
0
Anonymous Coward

Re: Rolling your own vs. getting Linux

"Trouble is QNX ain't free, making it a non-starter."

VxWorks isn't free either but there's at least one well known instance where a volume consumer electronics vendor swapped from Linux to VxWorks, on cost grounds. [In this case, the cost was the few cents per box saved by being able to use a cheaper SoC because VxWorks could do the same job while using significantly less memory than Linux, and there was [presumably] no per-unit licence fee for VxWorks, just a one time up front payment]

So there is a precedent.

1
0
Anonymous Coward

Re: Rolling your own vs. getting Linux

This is EVEN when you can trim down the kernel down to reduce its footprint? I'd like to know more about this, how VxWorks could outdo even a custom-trimmed Linux.

1
0
Anonymous Coward

Re: Rolling your own vs. getting Linux

Until a better answer comes along, you can go read about e.g. Linksys WRT54G, though the answers to your particular questions may be hard to find.

0
0
Gold badge

"And firewalls fall far short of offering protection, he said, for obvious reasons: they're oriented to block traffic from the outside, and if you haven't turned off UPnP, Things expect to open whatever ports they wish."

A few errors there. ... Even the cheapest routers have firewalls that *can* block outgoing connections if you want to. They also let you turn off UPnP and Things *expect* to be able to open ports whether or not you have allowed it. (They are merely disappointed if you don't.)

We don't actually *need* the changes (however sensible) mentioned in the article. We already have the tools we need. A bit of end-user education would go a long way here. Even once we have the changes mentioned in the article, it will still be possible for end-users to get it wrong.

2
0
Silver badge

"A bit of end-user education would go a long way here."

Except as a comedian said, "You can't fix Stupid." So how do you fix the problem when you have hopeless users?

1
0
Silver badge

Linux isn't part of the problem.

The problem is management/marketing not understanding the first principles of engineering, and intentionally, skillfully and pigheadedly refusing to listen to engineering when specing the latest InternetOfTat device.

10
3
Silver badge
Thumb Down

No.

The problem is the company making the device, not the software or developers. Yes developers will write dodgy code, but if you're a company and you're telling your devs to do 3 months of work in 1 month mistakes are going to happen.

But mistakes in code can be fixed, if the company decreed that the device could be updated. Does the company want to spend the money on each device to make it updateable in the future? And how long does the company intend to support the device to update?

These last two things alone are the core issues with not use IoT devices but with embedded devices that are interconnected to larger networks. Wasn't so long ago a journalist was able (with the help of a hacker) to drive an unmanned Jeep Renegade off the road remotely. That's been fixed yeah, but what would've happened if that issue hadn't been found out during the production lifecycle of the vehicle? Cars that were 7 years old, past any sort of warranty and to their 2nd or 3rd owner, now having the ability for any John Doe to drive the car via a laptop. And what if the actual implementation of the car's computer systems made it difficult for updates to be made?

Recalls do happen, obviously, but vary on the manufacturer. Toyota and Honda, in my experience, are fairly good with recalls even on older models. Vauxhall, not so much with their fireball Zafiras. And coming away from the car front, appliances. Indesit/Hotpoint are making a shit show of recalling their dryers even though they have caught fire and killed people.

12
0
Silver badge

Re: No.

*These last two things alone are the core issues with not just IoT devices

No coffee and no sleep makes wolfetone illiterate.

0
0
Anonymous Coward

Re: No.

"what would've happened if that issue hadn't been found out during the production lifecycle of the vehicle?

I recently read that a vulnerability in the Audi/VW remote control door locking system dated back to 1997 or thereabouts.

That would include the Audi I bought in 1999 then.

0
0
LDS
Silver badge

"create a separate network for those devices"

Just, the price and complexity will offset many users. Essentially, you need VLANs enabled devices (usually more expensive) and configure them properly (more complex). I did it so, for example, my Sky top box can see the Internet and nothing else - but I spent some hundreds euro for the switch and AP, and I know how to configure them.

Most users would need devices with IoT separate support available out of the box, but vendors may not be interested in delivering it. After all IoT is often a trojan horse to access more and more user data. Segregating them is not among the main aims of most makers.

0
0
Silver badge

I always thought failing to patch was the biggest security problem, after the user of course.

1
0
Silver badge

Patches in small hardware are Not At All A Good Thing. Like, at all.

- there's always a chance you brick the device on an update, and for Average Joe that's the end of the road. Exceedingly annoying if the dead device happens to be a lightbulb, even more so if it was ALL your lightbulbs. Yes, un-brickable bootloaders are feasible, but also exceedingly rare and hellishly hard to do properly in severely UI-constrained hardware (like a lightbulb).

- there's always a chance some more powerful computing device in your home (could easily be your phone or better yet your router) is already infected with something capable to identify and download appropriate malwarified firmware for your lightbulbs. Devices that can implement https and actually check they're really connecting to who they think do actually exist (barely just recently, in things like the ESP8266 chip, and poorly even there) but not every tiny chip is capable of doing that at all. You could of course also just simply sign firmware updates - right until your global key leaks / gets extracted / defeated etc.

- there's always a chance the absolute certainty that sooner rather than later one of the updates will alter or remove a feature or behavior that was the absolute cornerstone of your use case (or just breaks compatibility with something you need to keep using) - the only question more common than "how do I upgrade the firmware in <whatever>" is "how do I DOWNGRADE the firmware in <whatever>" and chances are the device (or the software that accompanies it) will actively try to prevent you doing that or even just avoiding the update...

- there's always a chance you'll end up in the nut-house trying to figure out why your Unambiguously Identified "Product X" just isn't willing at all to do / inter-operate with what is commonly known as something the Well Known "Product X" is quite capable of doing / inter-operating with, unless you're lucky enough to figure out you simply happen to have the "wrong" version of firmware and somehow everybody neglected to tell you that this is an Actual Thing with what is a stupid-simple, supposedly plug-and-play device (happened to me only yesterday, and I was getting close to reaching for an axe...).

0
0
Silver badge

So what do you do when (1) you have a device you use everyday but has a security hole big enough to drive a Mac truck through, (2) the only update available will defeat the very reason you use the thing, (3) your other hardware and the device's use case prevents you from segregating it, and (4) you don't have any money to replace the device?

0
0
Silver badge
Black Helicopters

Simple minded and lazy

Personally, I can't be bothered to worry about all this security theatre. I've got far better things to do.

I take a slightly different view.

To me, the advantages of the IOT far outweigh the disadvantages. I'd really like a totally unsniffable, from a wifi point of view, internet connection. I'd also like a fast, reliable connection all over my network.

So, NO WIRELESS at Zondek towers, NO "Smart" devices. One job done.

Sorry, I'll stay a luddite.

2
1
Silver badge
Holmes

Surely the only way to force vendors to get their act together is make them liable for any damage caused.

Problem solved, merci!

IoT MUST BE:

1. open source, full source code MUST BE SHIPPED WITH THE PRODUCT ON A CD/DVD

2. easily flashable

If it is not any of the above, FCC must revoke license, simples.

BTW, FCC, can you make ALL hardware manufacturers publish the sources to their drivers for FCC compliance, that will solve ALL security issues in IT ... for the forseable future.

0
4
Silver badge

Open source, or not

I'm not convinced about making vendors ship all source code as open source.

Thinking like a vendor...

- Source code integrates the hardware components and makes the Thing do Stuff. If I invest effort into doing something clever, then give the source code away, then I share my intellectual property with my competitors

- I *could* spend time ironing out as many bugs in the code as possible, or I could ship something a bit rougher and rely on the user community doing some trouble-shooting and bug-fixing for me....which is all well and good if end users are savvy, but there will be some less-savvy users who won't get into the code, and continue to run less stable / less secure Things

Better to force manufacturers to accept more responsibility/liability rather than going fully Open Source, IMHO

7
0
Silver badge

force vendors to get their act together is make them liable

Business have been getting away with murder for years. The chances of getting the law changed to actually move a step closer to being responsible are well below the IEEE smallest denormalized number.

5
0

Re: Open source, or not

Missing the point somewhat.

Those parts which are open source, ship as source code.

Those parts which are proprietary, ship as blobs ready for linking or executing, as appropriate.

Make sure that those who choose to rebuild the software can usefully do so, i.e. don't just do a raw code dump without any hint as to how to recompile it all. Makefiles, build scripts, build requirements.

3
0
Silver badge
Unhappy

My worry

is when insurance companies cotton on to this as an excuse to deny all claims.

"We see you had at least two IoT devices that were vulnerable to remote hacking and have determined that one of these caused your house to burn down."

6
0

What is not there can not be hacked

One needs to start using NetBSD, or another BSD Unix, to see where the speaker was getting at.

Instead of being chained in systemctl, tons of processes, dozens of mounts, open sockets and vague software dependencies, all is as one said it to be and fits on one screen.

I run reverse proxies in VM's with 64MB of memory and 2GB of diskspace.

The 80's style of system installation is a bit quirky in the beginning, but after some time, the elegant simplicity of it all starts to dawn.

5
0
Anonymous Coward

Re: What is not there can not be hacked

This is great - really. The only trouble with it is the mass education that would need to be provided for end users. Without being harsh, many of these have absolutely no idea of what they are doing with any technology. Computers, phones, cars - IoT is just the latest in a long line... I've been in support for the last 20 years and I can feel another headache coming... ;) (I haven't managed to shift the last one yet)

2
0
Linux

A better question is

Does that thing really need to be on the Internet at all?

1
0
Silver badge
Windows

Be careful what you wish for.

Way back in the day the programming of micro-devices was a black art, often requiring specialised hardware to program a chip and specialised developers who could program at assembler level in tiny amounts of memory. This lead to a high cost of development and maintenance and sometimes to unmaintainable code. Many chips, many different low level languages.

Oh, how we wished for a simple global development environment.

Now cheap as chips hardware has loads of memory and processing power and any Linux developer can work on the code. Linux on the desktop (well, on the lamp on the desktop) has finally artived. Yay!

You no longer need specialised hardware as most code can be developed on almost anything with a CPU. Develope in your own home in your spare time.

Hang on, amateur development and entry level unskilled programmers may be cheap but is it secure? If you use well known components with well known interfaces which are easily updated remotely then this adds ease and low cost to the attackers as well.

So be careful what you wish for. With cheap devices come cheap developers and cheap software.

Security is usually expensive. Long term support is ALWAYS expensive.

3
0
Silver badge

Re: Be careful what you wish for.

"Security is usually expensive. Long term support is ALWAYS expensive."

And users are CHEAP. Solve for secure users such that the Internet doesn't break.

1
0
Anonymous Coward

Easy Solution.....

"but how would you react if your lights started flashing every 200 milliseconds unless you paid Bitcoin to your attacker?"

1. Turn off light using switch at the wall

2. Replace Smart light bulb with a non Smart one

3. Read manufacturers response and then reset the control unit and download and update it once the fix is available.

(Use same procedure for any other IOT device)

It's a frikking light bulb not a nuclear reactor!!, way to overreact to something which would be a mild nuisance!

1
0
Anonymous Coward

Re: Easy Solution.....

OK, what if it's something a little more important, like a pacemaker monitor, which is used because doctor's visits are an expensive day trip? See the big about hacking pacemakers that can literally KILL people? That's just the proverbial tip of the iceberg.

0
0
Anonymous Coward

Re: Easy Solution.....

Yes, and because of those attacks security will be more in the minds of the developers and hopefully they will work to minimise the risks,unless their company values lawsuits and adverse publicity.

What annoys me is people continually trying to make fairly simple annoyances into major problems rather than just an easily countered annoyance, a hacked smart light bulb is not something that presents any great danger to life or property.

1
0
Silver badge

Re: Easy Solution.....

"Yes, and because of those attacks security will be more in the minds of the developers and hopefully they will work to minimise the risks,unless their company values lawsuits and adverse publicity."

I can trash your theory with one word: Redmond.

1
0
Silver badge

Re: Easy Solution.....

I wonder if it's at all possible to sue to have a company's source code openly published in the name of national security or whatever? Wonder if THAT would make for a good enough threat?

0
0
Silver badge

Re: Easy Solution.....

Never read the fine print, Charles 9? The answer is "no, because by using the code you agree not to sue the publisher, ever, for any reason".

2
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017