San Francisco Transit System Target of Ransomware

It's really bad. The ticket machines were hacked.

Over the next couple of years, I believe we are going to see the downside of our headlong rush to put everything on the Internet.

Slashdot thread.

EDITED TO ADD (12/12): More from Brian Krebs.

Posted on November 28, 2016 at 5:36 PM • 36 Comments

Comments

rNovember 28, 2016 6:08 PM

In other news, the rides were/are(?) free.

Good lesson for kiosk owners/operators, upgrade and secure or be phased out.

ClipperNovember 28, 2016 6:22 PM

Served them right, those systems collect data for surveillance purpose for the panopticon.

Clive RobinsonNovember 28, 2016 9:12 PM

@ Bruce,

I believe we are going to see the downside of our headlong rush to put everything on the Internet.

I agree, but it's not the whole problem, the "Internet" is made of "internets" which in turn are made of smaller "intranets". Which IoT etc devices are connected to, many of which have out of date insecure OS's and applications.

I had a reminder of this just a day or so ago. There is a brand spanking new supermarket just round the corner from a place I frequent regularly. Being in a "new build" it only opened a couple of weeks ago. Inside it has brand new shiny "labour saving" self checkout tills just out of their scratch resistant packing wrap...

The one next to the one I was using went wrong and was rebooted through MS Win XP with Wifi networking...

Now it would of course be remiss of anyone to sit in the adjacent coffee area with say Kismet (Android PCAP) or other PenTester kit, accidently left running on their phone/tablet etc... But an ordinary scan for the coffee bar Wifi showing the store network and seeing the self checkouts etc advertising their presence does seem a little remiss of those setting things up...

Oh and I wonder how the company that makes the self checkouts are going to explain a fault in the change "coin counter" that under certain change conditions will drop an extra two pound coin to the customer...

Perhaps describing things as a "headlong rush" is a little to staid a description for the current pace of things. But also misses the point about certain rquipment types, such as "self service" devices that are ment for a medium to longterm service life (10-20years) that get slow development / upgrade at best, and thus are often sold "new" with obsolete software...

Which brings us back to the idea of "regulation"... But do we need more, or just to enforce the existing legislation?

For instance there is "consumer law" in place in many jurisdictions and goods are supposed to be sold as "fit for purpose". Whilst in some jurisdictions B2B sales may not be covered by "retail" B2C consumer law, selling as "new" a device with "out of date" known to be insecure software, or long out of date practices such as "embedded passwords" can hardly be described as "fit for purpose" even for B2B sales in this day and age...

Oh one advantage of using existing legislation is it removes a significant time lag out of the process, where new legislation would have to build up it's own case law etc. A process that can take decades due to the way the legal process works. Another advantage of existing law is the older it is the less likely it is to have had it's teeth drawn by corporate lobbyists and special interest groups "needing" exceptions.

SamNovember 28, 2016 10:42 PM

It will be really scary when pacemakers and other medical IOT devices start connecting to the internet through cellular networks. Nothing like a remote controlled heart attack from half way around the world to ruin your life and that of your family.

Cars are already connected to the internet this way. I remember reading an article about hackers remotely shutting down car engines while people travel 70MPH down the highway and forcing the car breaks to come on.

EHNovember 29, 2016 2:45 AM

SFMTA has to have tons of dry copper or dark fiber between all of the stations that they could have used to isolate this stuff.

CassandraNovember 29, 2016 3:43 AM

Convenience and cost continues to beat security.

Running Ethernet cables to the Point-of-Sale devices costs more. The cables have to comply with electrical and fire codes, and the manpower cost to route cables is non-trivial. So a wireless network is far, far more convenient (you can remodel the store and move stations about easily, and add new ones, if so wished).

[Tongue-in-cheek] As for the use of WinXP: it could, possibly, have been Windows XP Embedded updated to Service Pack 3, the extended support for which end on 1st December this year (2016)...

https://support.microsoft.com/en-gb/lifecycle/search?alpha=Windows%20XP%20Embedded

The use of out-dated/obsolescent software in specialised machinery is not a new problem. There is a fair amount of industrial machinery 'out there' still using MS/DOS-based control systems. The hard bit is finding spare parts for the PCs the software runs on. The problem of updating old Android phones is also well known.

It is often cheaper to continue to run an old system than pay for a new one - and if the accountants have not depreciated it fully, there could well be strong incentives not to scrap it - industrial machinery can have accounting depreciation periods of decades.

You can still buy or manufacture the leather belt needed to transfer power from a steam-powered traction engine to a threshing machine. Hardware usually has a much longer potential service life than software, and I think it is a reasonable expectation that software should be capable of remaining fit-for-purpose for as long as the hardware it is running on. Astounding progress has been made with virtualization, emulators, and API cloning, so that old programs can be run on new cpus that are even a different architecture to the original: however, hardware compatibility is the Achilles heel here: many old systems are kept in service because they are tied to using obsolescent hardware connectivity - it's all very well being able to run a DOS program on an ARM Android device, but you can't plug in an ISA-bus interface card.

So, while you can encapsulate old software in a modern, supposedly more secure and capable Virtual Machine; there is no equivalent solution for hardware connectivity. This is a security challenge for the future - how to design hardware to maximise the chance of it being capable of being used, and in a secure manner, in the unpredictable future. How would you, for example, use the bidirectional Centronics interface (IEEE1284) disk-drive on a Mac equipped only with Thunderbolt ports? Or plug in an 8-bit XT ISA-bus controller?

This brings us back to Clive's point-of-sale device: it might be stuck on XP due to the availability of drivers and/or hardware.

I don't know what the solution is, but I agree one is needed.


AnuraNovember 29, 2016 6:13 AM

@Sam

It will only be a problem if the industry is insufficientlyly regulated (or regulations are poorly enforced) for things like formal verification, independent security audits, plans to ensure all devices can be updated safely and securely in a timely manner, there is graceful failure, and that your design and protocols are robust enough to protect against future unknown attacks, but even then, it's only if there is a lack of confidence in software after a few mistakes and lawsuits, and manufacturers of medical devices become antsy about deploying critical security updates that might introduce life-threatening bugs.

That's like, the only way it would be a problem. I mean, unless a company goes under from all the lawsuits and no one wants to buy them, then you would just have to surgically remove the devices from everyone who has them, since the software will never be updated again. No biggie.

Clive RobinsonNovember 29, 2016 7:32 AM

@ Sam,

It will be really scary when pacemakers and other medical IOT devices start connecting to the internet through cellular networks.

It's more an "IF" rather than a "WHEN" due to not just legislation but more importantly power constraints. Amongst other things the cellular network requires active devices to "re-register" quite frequently, even if they are not moving. Thus battery consumption is going to be quite high for "direct cellular network access". However this does not stop very low power indirect access using the basic ideas of BlueTooth ZigBee etc. Or even an "externaly energised" type system of a similar sort to NFC cards etc.

But hidden under this problem is a more major one few outside the medical electronics field talk about. One of the major reasons implanted medical electronics has such simple protocols is not primarily power consumption, but avoiding trauma room issues. Look at it this way, for an implanted device to be adjustable without the use of a scalpel it needs an extetnal --to the patient-- control station. With many manufacturers with very many new devices each year there is a danger that you could end up with an ER room needing hundreds of different incompatible control stations or risk being sued. But even then how do you identify which control station with which revision of the software is required in a timely fashion?... It has actually been suggested that tattoo's with make model and serial number be put on patients... However such behaviour obviously has privacy and discriminatory concerns. But so does any kind of RFID scanner etc if you think about it.

Aside from the ethical concerns we have still not come up with suitable general purpose communications standards for the electrical/electronic interface, let alone basic commands. As for security that is way way over in the left out field on the otherside of the carpark in comparison.

It's something I have been mentioning on this blog for a number of years now, but it appears stubbornly stuck in the longrass in that outfield...

Interestingly when you talk to doctors and surgeons who work with or in the field of medical implants, you get the feeling it's not something they think is of a high priority... Likewise the engineers who design the devices, their interests appear more driven by their employers marketing dept ideas, rather than potential patient safety issues.

As Bruce pointed out to members of the US Government a few days ago, his house thermostat is something he is unlikely to change. Well it might shock him to learn that the designed "in service life" on most household thermostats is not even a decade. However on a pacer and other medical implants the in service life is rapidly extending beyond a quater of a human life span, and it's the energy source design issues that are holding it back[1].

[1] At one point radio-isotope batteries were looked at but the "nuke/terrorist" fear and requirments to be safe during major accidents and cremations etc put paid to that for now[2].

[2] That said it appears that if you put a man made diamond around something like a C14 core it will produce small amounts of energy continuously with a half life of over five thousand years sufficiently safely radiation wise to be put in a human body (not sure I fancy the "recycling" option though), http://www.bristol.ac.uk/news/2016/november/diamond-power.html

65535November 29, 2016 8:53 AM

@ Clive Robinson

@ Sam,

'It will be really scary when pacemakers and other medical IOT devices start connecting to the internet through cellular networks.' -sam

"It's more an "IF" rather than a "WHEN" due to not just legislation but more importantly power constraints."-Clive

Very good point.

ChelloveckNovember 29, 2016 10:10 AM

@Clive, @Sam, @65535

Power probably prohibits connection to the cellular network, but there are already pacemakers with low power wireless communication to an external transceiver held near the patient's body. How long before that's an NFC or Bluetooth LE connection, and the transceiver is just an app on your smart phone? I don't think there's a technological reason why it can't be done.

Spaceman SpiffNovember 29, 2016 10:10 AM

Installing IoT stuff - so simple, only an idiot would do it! The "Time to deploy!" mantra gives short shrift to security. Are we surprised that this stuff, including our light bulbs, are being hacked? Default admin passwords are just the tip of the iceberg. Yes, good security is expensive. I have to wonder what this is costing BART per day right now.

trsm.mckayNovember 29, 2016 1:20 PM

Slightly off topic, but embedded systems getting obsolescent predates IOT quite a but. I have an acquaintance who works on replacement devices for nuclear power plants. Many times they have replaced several racks of equipment from the 60/70/80s with a single modern embedded system. These are essentially one-off creations, since even if the original system was sold to multiple plants, they are usually greatly customized. So they have to go back to original design documents when creating the replacement system.

Part of bringing up the replacement system is dealing with all the alarms and exceptions. They have often found alarms that have been ignored for decades, because the old system was not properly handling it, or because the original issue just became part of the background noise ("it always does that"). Something of a bracing problem, how humans are so good at adapting to an environment and an ongoing troublesome issue becomes "normal".

Today's security environment is an obsolescent acceleration factor, making systems intended for the long run inadequate more quickly. But it is not the only factor doing that, and keep in mind the hidden issues with replacement.

VinnyGNovember 29, 2016 2:22 PM

@Clive Robinson re self-checkout via XP: I suppose it would be extremely naive to suppose that anyone who set up self-check out kiosks with XP would have the sense to segregate the manned checkout registers into a different subnet. Meaning that swiping a card in the manned checkout line is likely every bit as risky as using the self-checkout. I usually use cash at the supermarket, I'll redouble my efforts in that direction.

Clive RobinsonNovember 29, 2016 2:59 PM

@ VinnyG,

I usually use cash at the supermarket, I'll redouble my efforts in that direction.

Yup in a number of respects cash is safer these days, and has been my prefered option for more years than I care to remember.

I even avoid cash machines, much to the anoyance of those "efficient market" types at the top of banks, who want to close branches etc. However unlike machines atleast you can make the counter staff smile when you visit :-)

albertNovember 29, 2016 3:21 PM

@Cassandra,et al,
"...The cables have to comply with electrical and fire codes..."

In the US, Ethernet is and always has been Class 2 (low-voltage) wiring. Aside from meeting Class 2 specs, the only restrictions are hazardous environments (hopefully, retail stores aren't:), and 'plenum' installations (often above-ceiling areas are used to replace return air ducts for HVAC systems). In that case, the wiring must meet fire safety regs.

Practically all Ethernet wiring today is 'home run', that is, each node connection runs to the server. So even though CAT5 cable is cheaper than coax, it's more expensive to connect.

Businesses always go for convenient and cheap. (Gee, that's a lot like individuals. Imagine that!)

A 'hard-wired' business (w/o wifi) will never be hacked, except through their server internet connection.

RE: Human embedded devices. For God's sake, do we really need nuclear devices inside us? Let's stop this insanity now.

Anyone ever used an electric toothbrush? That technology can be used to recharge a battery, and read/write data. It's safe, and range-limited by design, not 'passwords' (which should be relegated to back to "Joe sent me" speakeasies).
..
@trsm.mckay, interesting, but scary. Certainly, embedded system technology has advanced dramatically since those systems were designed. ATC systems are being upgraded, to be technically better, and simultaneously, less secure. Those Space Shuttle flight control computers did a pretty good job for quite a long time. I hope those systems 'your friend' is working on aren't internet connected, or (God forbid) wifi'd.

. .. . .. --- ....


AnuraNovember 29, 2016 3:24 PM

@Clive Robinson

Umm... I hate to tell you this, but it is their bosses making them smile; they smile at everyone.

Clive RobinsonNovember 29, 2016 3:41 PM

@ Spaceman Spliff,

Installing IoT stuff - so simple, only an idiot would do it! The "Time to deploy!" mantra gives short shrift to security. Are we surprised that this stuff, including our light bulbs, are being hacked?

You forgot to mention another underlying problem "lack of manpower". These "idiot boxes" have such a low "Time to deploy" because that's "what the shareholders want".

It has another knockon effect few vocalise, the lack of manpower givrs rise to "expert scripts" by a few experienced admins, these get "copy-n-pasted" to "me-to" sites which get cut-n-pasted by much less experienced personnel, who don't realy understand them, but make small changes anyway.

The problem with this cut-n-paste administration is what makes life easier for quite a few admins, also makes life a lot easier for attackers...

But for some reason we appear not to learn from past issues such as the dangers of "mono-cultures"...

MikeANovember 29, 2016 4:29 PM

Hardware life is only relevant if either the manufacturer will keep updating at least the security components (unlikely past about 5-10 years these days) or you can maintain it yourself (unlikely for any computer capable of running a browser and built from approximately now until "The Revolution", as "managed" systems and "code signing" are rolled out pervasively).

Contrary to the cheerful thought in the Blaze, Clark et al. "Honeymoon" paper, I very rarely see an "upgrade" that fails to also introduce vulnerabilities. They may not be immediately found, and they may not be intentional, but Sufficiently Advanced Cluelessness is indistinguishable from Malice. Yes, I know that the plural of anecdote is not data, but the history of modern mainstream OSes is that monetization of customer data is _way_ higher priority than securing said data from evildoers (even those defined by "did not pay vendor for this info").

Clive RobinsonNovember 29, 2016 5:20 PM

@ Anura,

I hate to tell you this, but it is their bosses making them smile; they smile at everyone.

That's what the bosses would like to think, but lack the empathy to test. The reality is that it's actually quite hard to fake a real smile all day.

For some reason small children and those of more mature years tend to spot false smiles more easily than younger adults, who possibly don't need that defence mechanism as much.

I'm also well known by the counter staff[1] in the few branches I use, partly because I'm quite recognizable[2] and partly due to swapping baking and other recipies. But also in part due to the fact I do things a certain way each time which reduces the potential for fraud greatly. Oh and in atleast one branch they had to get me carted off to hospital when I keeled over due to an annoying medical condition.

[1] I found out when wearing the green that the way to get the best out of people is to show you are genuinely interested in them, and respect what they do. Yes it takes time but it usually makes both you and them feel better in the long run.

[2] It's not only small children that have been known to point at me and say "santa". For some reason I'm way to memorable to people, I go somewhere new and somebody I've not seen in thirty years will just pop up and say hello. I've even had young ladies come up and hug me, and some even call me by name, and it turns out that I know their parents and some years ago I fixed their bike or favourite toy, helped them with their homework, fixed the computer or taught them to sail, canoe, put up a tent etc and even taught their grandparents how to use a computer. Even kids who are in the same school as my son call out to me and say hello when I'm shopping, or say to their parent's "That's Alex's dad", likewise the teachers nod and say hello. Even doctors, nurses, porters and other patients and their relatives, will say hello and have a chat.

RolandoNovember 29, 2016 6:25 PM

> Over the next couple of years, I believe we are going to see the downside of our headlong rush to put everything on the Internet.

I'm wondering whether we'll also reconsider the "single absolute root-of-trust" model we tend to use for system administration. Usually, one Kerberos server, acting alone, can grant the authority to do absolutely anything on a network. And one administrator, acting alone, can cause it to do so. This makes them both huge, valuable targets.

ab praeceptisNovember 30, 2016 12:22 PM

mikey

Didn't you read the manual? wifi ssh into your shoes using "123456" as password.

Clive RobinsonNovember 30, 2016 1:30 PM

It would appear that "transit card" payment/ticketing is suffering a bit of the winter maladies...

This PM I've "had occasion" as they say to use the Public Transport Service in London...

At a South West Trains(SWT) station there are hand written notes on all the ticket machines saying that there are problems with the Transport For London "Oyster Card" system and not to "top up" as it will not register...

I know the Oyster card is a "bolt on" to the SWT ticketing, and the Oyster is the much maligned Philips MiFare system with a centralised system designed and operated by another company with a fairly poor rep as far as computers are concerned...

Time to get the comfy chair and an extra large bowl of pop corn kick back and await the results (if they dare tell the truth).

LeilaNovember 30, 2016 3:07 PM

No one expected that computer operating the infrastructure to be connected to internet! What a security mistake!

CassandraDecember 1, 2016 8:06 AM

@albert

"...The cables have to comply with electrical and fire codes..."

"In the US, Ethernet is and always has been Class 2 (low-voltage) wiring. Aside from meeting Class 2 specs, the only restrictions are hazardous environments (hopefully, retail stores aren't:), and 'plenum' installations (often above-ceiling areas are used to replace return air ducts for HVAC systems). In that case, the wiring must meet fire safety regs.

Practically all Ethernet wiring today is 'home run', that is, each node connection runs to the server. So even though CAT5 cable is cheaper than coax, it's more expensive to connect."

Ethernet is low-voltage, but there are restrictions on how it is routed in relation to nearby power cables. Essentially, you have to avoid a situation where a fault could cause the Ethernet cable to carry a dangerous voltage, which usually* means it cannot be routed in the same trunk as power cables. Similarly, while plenum-rated cable is easily obtainable, there is hassle associated with routing a cable through a fire-barrier, so it is very beneficial to have a switch/hub/router in the same room as the multiple sets of equipment being connected, so you only have to worry about the 'permanent' uplink from the switch/hub/router going through a fire-barrier. From a cabling infrastructure point of view, it is much, much, simpler to wire up a single Wireless Access Point to provide coverage in a room than a set of wired connections, but wireless infrastructure brings its own security challenges.

Given a choice, I would usually prefer a wired infrastructure.

*As ever, there are exceptions. Standard Twisted Pair Ethernet was not designed to fit in with electrical safety codes - it is not 'intrinsically safe', and doesn't meet the definitions of Extra-Low-Voltage electrical classification. There are solutions for using Ethernet in industrial environments, but the main thing to understand is that you cannot just route Ethernet cables where you like, and you need to work with experienced electricians and cabling contractors. Assuming an Ethernet cable can't give you a fatal shop could be the last assumption you ever make.

albertDecember 2, 2016 7:10 PM

@Cassandra,

It eventually comes down to money, doesn't it. Commercial developers, contractors, and ultimately, equipment manufacturers, are some of the stingiest folks I've met. It's a good thing we have the NEC, etc., otherwise, we'd all be in trouble.

I wouldn't expect CAT5 cables to be intrinsically safe. I've done installations in environments that require it, and they are super expensive. On regular industrial machines, we often needed to 'pipe' the Ethernet just to reduce interference.

The problem is simply this: there is no incentive ($$) for a developer, business owner, or leasee, to pay extra for secure wiring. They are either unaware of potential hacks, or are simply willing to throw the dice, and let the insurance company handle it.

When all is said and done, more is said than done :)

The WiFi chickens are coming home to roost. The Java and the Flash chickens are already there.
. .. . .. --- ....

shufflerDecember 4, 2016 9:38 AM

Here is an interesting solution that will probably help mitigate some hacking attacks:


Solution to JIT-ROP cyber attacks: Scramble code quickly
http://www.networkworld.com/article/3146563/security/solution-to-jit-rop-cyber-attacks-scramble-code-quickly.html

A new software development technique promises to end destructive exploits from hackers. The concept is to continually, and repeatedly, rearrange the program’s code while it’s running—and do it very quickly. Doing that shuts down the hacker’s “window of opportunity” because he doesn’t know where to find bugs to hit with his poisonous attack. The scrambling occurs over milliseconds.


Not sure how scalable Shuffler is however?

Original source for above article:
http://datascience.columbia.edu/new-software-continuously-scrambles-code-foil-cyber-attacks

Clive RobinsonDecember 4, 2016 10:05 AM

@ Shuffler,

A new software development technique promises to end destructive exploits from hackers. The concept is to continually, and repeatedly, rearrange the program’s code while it’s running—and do it very quickly.

This is far from a new idea, it's not even a new development, that is there have been --problematic-- research prototypes developed before.

Whilst some problems are obvious some less so but quite as devistating as not having the system if exploited.

Think for a minute how you would shuffle things, you obviously want to keep the overhead low, so shifting code in RAM is not desirable. You can use as others have the paging mechanism to do tricks with VM via the hardware, but as with disk drives you have the question of inneficient use of storage as pages are of fixed size and called code rarely.

But think a little further on what shuffling actually means... Then how deterministic it will be in it's apparent randomization, and the ability of an attacker to detect and synchronise to it... If they do then it's game over.

When you analyze the idea and compare it to other mechanisms that give much greater protection and have way way less overhead you'll realise just what a desperatly bad idea it is...

I suspect @Nick P, ab praeceptis and one or to others of the usual suspects will want to add comment (if you are awake @Wael ;-)

ab praeceptisDecember 4, 2016 10:41 AM

Clive Robinson, Shuffler

"I suspect @Nick P, ab praeceptis and one or to others of the usual suspects will want to add comment "

A very short one (partly because you already hit the blabla with a large hammer - thanks for that).

aslr **2! Hurray!

Plus a tiny little side note: The whole code zoo is already riddled with bugs beyond hope. Introducing yet another level of complexity, and a lottery like one at that, is just bound to create safer software.

This week only! Be sure to be among the first as supplies are limited! Eiffel tower only 1 Mio $, brooklyn bride also just 1 Mio $! Take both and save 250.000$!

WaelDecember 4, 2016 9:11 PM

@Clive Robinson, Shuffler,

The concept is to continually, and repeatedly, rearrange the program’s code while it’s running...

First, you need to identify thye exact problem. Second, you need to show how randomization achieves the claimed purpose.

if you are awake ...

Of course I was awake (until 7:00AM) when my skull finally gave up.

This is far from a new idea

There is ASLR, code obfuscation (although static in nature; compile-time.) Then there is self-modifying code. I suspect @Shuffler is talking about a mixture of dynamic (i.e.: runtime) obfuscation plus a more granular version of ASLR that acts on a function level plus self-modifying code. Me? I think self-modifying code developers need to be disemboweled (with a lightsaber, may the source be with you) because they are in a state of sin if they believe adding this level of complexity improves security.

Clive RobinsonDecember 5, 2016 12:15 AM

@ Wael,

First, you need to identify thye exact problem

Are you going "old english" on me ;-)


@ Wael, shuffler,

First, you need to identify thye exact problem. Second, you need to show how randomization achieves the claimed purpose.

From my point of view the argument for any kind of address map randomization, strength / advantage has been more an assumption than a tested tactic. Thus it has that horrible "crypto taint" that you hear occasionaly about "the creator of a system not being able --or wanting-- to break their creation, assume 'if they cannot then nobody can'".

The main assumption of any kind of address map randomization is that "an attacker will see a different layout that is unique for each system" thus each system will require a unique attack. This argument then goes on with that assumption as a given.

But is it true?

Obviously not at two levels...

If you think about what you are doing you are taking a program and cutting it into pieces, then rearranging those pieces, therefor you are,

Firstly looking at a set of permutations not unique pieces of code.

Secondly each piece is most likely selected along some recognizable interface point not a random point (though that could be done, it is much more complex to do so).

Therefor you can take another look at the situation in memory from a finer grained "tasklet" or "thread" view...

The first obvious question is "what has this change gained you? And the answer is "not much". All you have done is changed the attackers job from locating a vulnerability in a program to locating a vulnerability in a tasklet or thread.

Yes it sounds harder but is it?

The answer is no not realy. Many attack vectors are found not by searching the memory but by fuzzing the input. From the input perspective the address map randomization has not changed the function of the code or the order the parts of the code are executed... Thus the attack vector is effectively "still in the same place" in time/order and can still be activated in the same way.

The question then is having been activated in the same way can it be exploited in the same way. Well if the attack is based on the actuall input the answer is yes but with maybe a little more difficulty.

We know that the code space has been rearanged but what about the variable space in the stack and in the heap?

Well as the code still executes in the same order the variables will get assigned in the same order. Thus although their absolute position may well have changed their relative position with respect to each other probably has not. Thus an attack that uses an offset from some kind of base pointer will still work the same way, even though the base pointer value may well have changed...

You can keep going through like this and it will tell you as an attacker how you change things. The main point being the attacker moves from a "fixed memory map" based attack viewpoint to a "execution sequence and relative offset" viewpoint. Yes it's different but is it that much harder?

The answer from my own experiments is it depends on factors other than the address map randomization, such as the way the code is written especially in common functions... That is code designed to be re-entrant or reusable tends to be more vulnerable due to using relative not absolute addressing, based on offsets from a base pointer which is already setup for the attacker.

The implication is that the security of making stack and heap space non-executable would be of a lot more hinderance to an attacker, and if they can get over that fence then the rearangment of the memory map will not present anything as significant.

Clive RobinsonDecember 5, 2016 1:03 AM

@ Wael, shuffler,

Oh I forgot to add, the question of if it could actually make things worse...

The expressed "newness" of this is that it will rearange the memory during program execution. But it's left ambiguous as to which memory gets changed, code, heap, stack (possibly for "prior art" claim reasons).

I expect currently it's only the code space, because rearanging pointer based access can of course break things baddly. Which in turn will change the way the programmers write their code...

However it raises the question as to the "how" of the rearangment. Obviously something has to be changed that means something has to be written to memmory... Ops.

From a security perspective, you do not want to have code space writable during execution in the same way you don't want variable space to be executable.

With the likes of static address space randomization having code memory writable during execution is not required. However for dynamic randomization it has to be to rearange the memory.

If the rearangment is done by the process it's self then the code space will be writable during execution. If it's done by another process then in theory with sufficient privileges it can make the code space writable, make a change and then switch it back to read only...

This then brings up a question of how do you ensure it definitely does this... Well the answer is by various OS specific mechanisms that allow you to lock out the program execution process whilst the rearanging process is active.

This is going to give rise to the potential for either deadlocks or to long breaks in the execution time. IF and it's a big IF things are done properly (they rarely are). If done baddly then there is the chance that an edge case may leave the code space writable...

Programers hate long breaks in execution as can be seen by the many "The Garbage Collector is killing my performance..." type comments that pop up. I dread to think what they will say if the get deadlocks... the least of it will be that they are "not pleased"...

But there will be other effects that cone up as edge cases from time to time, as that is often the nature of such things, thus "style myths" will arise.

That is the programmers will be more likely to change their programming style. Thus yes they may well code less securely even though they may think they are making things better, such is the power of a "style myth".

WaelDecember 5, 2016 3:56 AM

@Clive Robinson, @Shuffler,

Are you going "old english" on me ;-)

A small typo that looks cool ;)

Re: "Randomization"

The fundamental problem with this approach is the reactive nature of it. It's the problem of wearing the "attacker's hat" again. It goes something like this .,.

Bad boy: Look! We can manipulate the stack pointer and execute arbitrary code.

"Security schmuck"; Well, let's put a token (a random one, too) on the stack! Ummm.., let's call it a canary! We'll also validate inputs (they frequently don't)

Bad boy: Canary, eh? Hey! We can corrupt the heap and manipulate function pointers!

"Security schmuck": Ummm... let's create a HW enforced no execute bit! No data in the .data segment can be executed...

Bad boy: Dang it! Well, well, well! We can still return to libc! In fact, we've doing that for quite sometime using ROP! OpenSSL, anyone?

Security Schmuck: Crap! How about if we randomize the location of loading libraries so that the bad boy can't find the right libc function to return to?

Bad boy: Yea, right! We can still find it, ASLR my foot!

Security Schmuck: It's gotta be the programming language! F**k "C" and all it's cousins!

Bad boy: "C", Schmee...

Security not-so Schmuck: Let's look at it from a different perspective: air-gap, proper adherence to security principles, rethink the fundamentals... enter C-v-P.

Bad boy: goddamn! We're screwed.

Security Schmuck: Don't worry, we need our jobs. We'll take care if you and sprinkle a few bugs here and there ;)

enderDecember 6, 2016 7:56 AM

Regarding XP on checkout machines: they probably run XP POSReady 2009, which is supported until April 2019 (this is also why you can trick Windows Update into still giving you security updates for regular XP for free - you just make it think you're running POSReady).

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.