I know it's easier to deal with it that way, but just to limit the exposed code, it could be based on something much more restricted. If it was small enough, it could even reboot / netboot itself between each operation to prevent any modifications being stored locally.
The actual reason OS/2 is gone and all these ATMS are running Windows is because of companies like NCR and Diebold lobbying the government to put new language in the Americans with Disabilities Act [1]. It required every ATM to be capable of text-to-speech translation which the older hardware and OS/2 systems were not capable of (most of the machines I was pulling had 133Mhz processors and less than 64MB of RAM). This meant 1) new hardware sales, 2) new software sales, and 3) selling custom ad campaigns to run on the shiny new color screens and new hardware.
The industry had been stagnant for awhile in hardware and software sales, the deadline of March 15, 2012 was a great shot in the arm for NCR and Diebold. Lest you think this really was about helping people with disabilities, the vast majority of ATMs that I 'upgraded' were drive-through units sitting on concrete pallets in bank parking lots too high or too inconveniently placed for anyone to use unless they were driving in a car. I did get some very positive feedback from the blind and their friends(who knew the IRS employs so many blind folk?) when I installed some of the walk-up units, but the large majority were drive-throughs.
[1] - http://www.americanbanker.com/magazine/121_10/atm-accessibil...
Bah.
I thought in the US, things might work differently though, but it seems just like "the grass is greener on the other side"
One way NCR/Diebold would screw customers is by having the software upgrade process take so effing long. If you wanted to upgrade the software on one of these machines it was multiple CDs with a total boot / reboot / loading time of 5 to 6 hours. I've torn through all the code and programs I could find on those machines while in the shop, there is NOTHING that could possibly be taking that long to load and install. The entire customer interface is an XML config file with a few PNGs and text-to-speech running for selected parts of the XML. (This is also a fun way to hack an ATM to say things like "FEED ME A STRAY CAT"). We really suspected the companies greatly padded the install time to increase their service bills. We got the contracts to upgrade from the regional banks because we would instead build new cages with the correct CPU/RAM/audio spec, preload the software with a bunch of cloned hard drives, swap the cages and then bring the machine back on the network. This was MUCH cheaper than paying the factory technicians.
Don't even get me started on what NCR/Diebold do with the DMCA. They would do things like releasing an identical hardware component (receipt printer, etc.) but with a new driver, and if anyone bought a used component (for about 10% of the new price) and dared to update the driver so it would work with newer machines (which refused to work with the old drivers) they would sue and win.
So you're surprised every time you see an ATM? They're all Windows-based (unless there are still some OS/2 ones around, which would not surprise me much).
> Why would a full, general-purpose OS be included in those machines that need to do just under 10 operations?
Among other things: Because the maker of that OS defined an API (XFS, mentioned in the article) to access the custom peripheral hardware used by ATMs.
> but just to limit the exposed code, it could be based on something much more restricted.
What exposed code? These machines aren't connected to the internet, talk only to their own servers, and have a very limited end user interface.
No. I'm also surprised every time I see people constructing sql queries by joining strings with no escaping. Which also happens all the time.
> What exposed code?
We're commenting on an article about a trojan using dynamic linking to inject itself. Try doing that with code loaded straight from flash which is verified by a separate chip. These machines have a chance to verify their whole code before running... but can't really do that if they're running a general-purpose OS. That's what I mean by exposed code. They should crash/report issue as soon as any modification is made.
My point is that a system's resilence against manipulation is not all that important if the way it is operated affords little or no opportunity for manipulation. Note that the trojan described in the article apparently requires a criminal to be physically present at the machine to harvest the collected information and says nothing about how the machine would get infected. Remote infection (which is impossible for a normally operated ATM) wouldn't be much use when profiting from it requires physical access, so I infection probably also requires physical access to the inside of the machine. That's a worst case security scenario anyway.
I agree. That's why I haven't even mentioned it. Running from flash and self-verification is already what most payment terminals do. This is not something new.
Then there are some ATMs running Windows XP. Which, yes, is really dumb.
Look at it the other way - the only functional difference between a payment terminal and an ATM is the cash dispenser. Payment terminals implement modems, networking, bluetooth, crypto (actually that's done in hardware anyway, you just talk to a chip), UI on an almost completely custom system - it's being done right now.
Signed NCR, Diebold, et al.
I am from Russia, so corruption may be explanation.