Schneier on Security
A blog covering security and security technology.
« Friday Squid Blogging: Giant Squid Caught by Japanese Fisherman |
| SPARROW II: NSA Exploit of the Day »
January 27, 2014
New Security Risks for Windows XP Systems
Microsoft is trying to stop supporting Windows XP. The problem is that a majority of ATMs still use that OS. And once Microsoft stops issuing security updates to XP, those machines will become increasingly vulnerable.
Although I have to ask the question: how many of those ATMs have been keeping up with their patches so far?
We have far to go with our security of embedded systems.
Posted on January 27, 2014 at 6:32 AM
• 60 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
"how many of those ATMs have been keeping up with their patches so far?"
Somewhere I read a statement of a bank manager (? sorry, don't find the source) explaining that ATMs are not connected to the Internet and communicate only via a private network with the back-end systems.
I think it's not unlikely that those bank-specific application servers don't push (and never pushed) OS upgrades.
@renke The problem, as we know from hundreds of bad examples, is that systems that are not supposed to be connected to the internet very often are.
Windows XP Embedded will be supported until 1/2016, so at least they have a bit longer, although it's about time they move to a newer platform.
ATMs are likely to run Windows XP embedded. Which is supported until at least 2016.
So either they have been patched regularly, in which case they're fine (from this point of view) until 2016. Or they haven't, in which case XP's end-of-life, in 2014 or in 2016, won't really make things any worse.
Security support for Windows Embedded POSReady 2009 (The last version based upon XP) ends in 2019.
Its also the only one for which Windows Update is supported (For the other versions, updates have to be deployed by rebuilding the Windows image, as I understand it, which makes me suspect they never get patched).
We must hope they're not connected to the internet, I suppose.
The article is very short and doesn't go much into detail, but is essentially right: UDP is nicer than TCP in a lot of applications, but can't be used for all of them.
Things will change in the future and UDP will be used everywhere for everything, but only with an other protocol on top of it.
This is what new protocols like CurveCP, minimaLT, QUIC and the one I'm working on, Fenrir do.
Basically UDP is great, as long as you re-implement congestion control on top of it. UDP is only used to pass through firewalls.
Might not be easy, but totally fine.
Here is an article from an International Engineering Trade Pub about using UDP for M2M (IoT) because it is faster then TCP/IP:
Sounds like a bad practice to propose.
#1, As someone who has been writing network software since 1990, this is not news. Of course UDP is faster than TCP. Connectionless protocols are always faster.
#2, There is nothing that makes TCP superior over UDP for security. It's up to the protocol designer to add the security, regardless of which is used.
Yeah, discontinuing Windows XP is going to wreak havoc across the globe, "Fire and brimstone coming down from the skies! Rivers and seas boiling!" "Forty years of darkness! Earthquakes, volcanoes..." "The dead rising from the grave!" "Human sacrifice, dogs and cats living together... mass hysteria!"
And only Linux can save the lives of millions of registered voters.
ATMs, vote tallying machines, lots of stuff has horrible, gaping security holes in it. Millions upon millions of consumer records are breached, and nobody learns anything. Data keeps going walkabout because everybody just has to have a live copy of customer data on their notebook computer.
Since UDP performs no handshake and therefore can perform full transactions in one packet the source IP address can be spoofed much more easily. Shifting to UDP sounds like one of those standards changes pushed by the NSA to weaken net security. Requiring a verification connection back to the purported source of a transmission (as TCP does) seems to be something we want to do more of, not less.
It is perfectly o.k. if your application is a) capable dealing with packet loss. b) packet loss does not introduce more cost than using a reliable protocol.
It is especially suitable when a delayed packet has the same value as a lost packet (Streaming, RTS, etc). Keep in mind that TCP is a stream based protocol. If you lost packet N but received packet N+1 you cannot read the data from packet N+1 until you finally received packet N.
PS: One thing which is left out by the article. You have always to anticipate packet loss with UDP. Even if source and destination are localhost. Failing to do so will lead to deasaster.
@YeahSure: If you rely on that "property" of TCP than you are a complete fool.
@FiveElevenOne: "If you rely on that "property" of TCP than you are a complete fool."
Well, if I were convinced by that level of argument I WOULD be a complete fool. Do you have any suggestions about how to subvert it? After the famous Mitnick attack led to improvements it is not really feasible to guess sequence numbers.
Why are you quoting "property"? Are you saying it is not a "property" or have you missed your wake-up this morning and your hands are shaking and hitting keys at random?
Perhaps you have heard of "Defense in Depth"? Anybody who knows what they are doing doesn't rely on any one thing but uses levels of protection. These days what can you rely on? But the TCP handshaking makes attacks a lot harder.
You are welcome to contradict me with actual information.
One thing that many people don't realize about XP Embedded: it's ridiculously modularized, and the manufacturer can build an image that excludes anything they don't need - there are like 12,000 components you can include or exclude.
Don't need a mouse driver? Don't care about NTFS or USB? No Notepad.exe? RPC and DCOM make you nervous? Just check a box; the list is unbelievably comprehensive.
You don't even have to include a desktop (or a browser) if you don't want, booting directly into your application.
These go a long way to reducing the attack surface of the device.
Of course, the vendor can still screw up - and surely many will - but it's not the same as shipping Windows XP Home Premium in every ATM.
Except very few ATMs run XP-embedded
XP-Embedded needs special skills, it needs extra tools to build and verify the image and other tools to distribute it.
the licensing is also a pain - unless you have the special tools and skills to use them.
However just using XP in an ATM means you buy the cheapest PC clone from the cheapest supplier, roll out your corporate site license of XP just like all your other desktops - then forget about it.
Done right, old machines with old software can be entirely secure. First, there should be no direct access to the computer (the hardware is physically secure). Second, there should be no public access to network. Third, all unneeded services that talk to the network should be turned off. (The last is not strictly needed if you can always assure the second, but protects against lapses.) Nothing new about this.
Bruce, I am a little disappointed with this post. Assume there is a guy out there who really did lock down access properly to their deployed network. If at some point a haired boss in his management pool reads or hears of this missive, and panics ... you are going to cause a good guy grief. (You can bet on this.)
Of course badly secured machines are different story, but in that case...
But they told the EU that IE was part and parcel of the OS, I so confused in the utterly range now :(
NobodySpecial hit it on the head. Most ATMs don't run XP Embedded. Manufacturers won't honor their warranty/support if you apply patch updates to those machines.
Also, while they don't connect directly to the Internet, it's very likely that they're connected to the LAN, which means any virus that's able to "see" the device can exploit vulnerabilities.
Anyone remember Y2K?
The price of fixing Y2K problems got exponentialy more expensive the closer New Years eve got ever though the problemhad been identified and articles published about in 1962...
So with that amount of warning and nothing being done for Y2K what chance the ending of support for Win XP?
We already know that presure on MS has caused them to move the EOL date a half dozen times. The time I remember the most was with the birth of netbooks running Linux MS bowed to perceived comercial presure and produced a cut down version of XP specificaly for netbooks...
I suspect that there are many businesses who won't migrate off of XP even if MS gave away free copies of Win 6/7/8 and throw in a free copy of Office as well. Simply because they cann't upgrade the systems.
This is especialy true of any embedded system, including industrial, medical, telecomms, power, water and military systems let alone advertising signs and the odd ATM system.
It's a symptom of a much deeper problem of executive short sightedness induced by stockholders and driven by the banks.
Most business executives know they are playing a game that is a cross between "Pass the hot potato" and "Russian Roulet" where the only sensible career stratagie is be bold talk it up and jump before it gets beyond the initial phase. That way if others make it work, you claim it as a success because of the strong foundations you put in place, and if it fails you blaim those who followed you for not following you brilliant scheam. Either way you are preparing to jump yet again.
For those who can not jump the solution is to get in "consultants" if they get it right you claim it as a success if it failes then it was due to other edecs placing to much faith in the consultants.
In the mean time cost cutting beyond the bone is the norm, preventative maintanence is cut beyond any posability of working so "fire fighting" is the norm for engineers and technicians and the only way to get required funding is to frighten the execs with jail or death...
So it's turned into an "asset striping/destroying" free for all "race to the bottom" clutching your copy of "Atlas Shrugged" or the latest "free market thinking" from some economist who's research has been funded by the worst tax avoiders known to mankind...
ATMs are cheap PCs bolted onto the top of a safe. And Banks are notoriously cheap and thus you won't find XP Embedded used. That just increases support costs. ATM networks SHOULD be isolated but as we see from various ATM outages over time (see Bank of America) malware can find its way onto the boxes. And fixing them can be difficult in some cases.
But ATMs tend to be knocked out by accident more often than not.
As a long time embedded systems programmer, it's not that you can't patch binary - I've disassembled and patched many binary codes for which I had so source. The greater problem is embedded systems with code in Read Only Memory (ROM that's one-shot burnable or in the chip mask). These can never be patched - you can't insert a jump instruction. Lots and lots of systems do not have flash memory - the lower the cost target, the more likely it's ROM.
I think a lot of these ATMs running XP have only just recently been upgraded from OS/2
"Yeah, discontinuing Windows XP is going to wreak havoc across the globe..."
I suspect that Bruce's key point in this post pertains more to Clive's:
"In the mean time cost cutting beyond the bone is the norm, preventative maintanence is cut beyond any posability of working so "fire fighting" is the norm for engineers and technicians..."
It's our craptastic norms that are at issue. They result in perennial drag on what should be a high-functioning society/economy. Extreme, mass failure is (almost) never a legitimate concern in re the millions of appliance computers that now litter our landscape. It's the normative, highly preventable inadequacy that is the problem.
They're all vending machines waiting to swallow your dimes without crediting you, or coffee makers that randomly burn your brew.
Except, you can never tell whether someone's burnt your afternoon coffee for profit, or whether you've merely encountered an "acceptable" bit of cost-benie vetted suckitude.
This is related to the long standing problem of patches not being pushed for outdated Windows, in general. And, can be related for pirated versions of Windows not getting patches. These problems have been ongoing for quite some time, though MS has made some changes to some of their update policies.
Having performed pen tests on embedded systems, and worked with vuln analysts who have broken atms and similar boxes... my own viewpoint is the security is probably going to be crack, anyway... though as another poster pointed out they are likely to have reduced foothold, and yet another, these are connected apart from the actual internet.
Really, getting onto that network is probably where some attacks are going to come from, as they have done with some PoS attacks.
This besides the plethora of existing attacks like skimmers, and a variety of methods to bust into these boxes.
In terms of updates, Windows XP actually has been very well looked at, and Windows 7 and 8 is so different in code base... it is likely that many future vulnerabilities found will *not* be backwards compatible. Add to that the limited attack vectors an ATM gives, whereas a lot of attack vectors new attacks will be found in are designed for hitting consumers often by client side type attacks -- not network based attacks.
I am sure, like PoS systems, and bloomberg networks, though atm networks are a nightmare of backwardness and possible attacks. Far less so, probably, when dealing with the very savvy larger financial companies... but far more so when dealing with the little run of a mill atm solutions.
@ Preston L. Bannister
"Done right, old machines with old software can be entirely secure."
I 100% agree. You must * LEARN * how the machine works and what kinds of techniques the systems use to transfer data, and what kind of data is transferred as well. From knowing that, the user can become savvy and allow OR disable certain vectors of communication which can harden the overall security of the system by using analytic tools, software.
I would not wonder if NSA searches for "terrorists" in counterstrike. But in angrybirds?
NSA apparently thinks that these apps are a goldmine.
According to this article, every usage of the localization services of your smartphone gets noticed by GCHQ. NSA is also interested in the following "home country, current location (through geolocation), age, gender, zip code, martial status – options included "single", "married", "divorced", "swinger" and more – income, ethnicity, sexual orientation, education level, and number of children."
The leased lines and the custom vaguely documented protocol are the only things that kept it from constant jackpotting when XP WAS supported..
Bank IT engineers and contracted development firms are extremely lazy, just look at the network and software designs..
Even the pin you use at a POS or ATM is in the actual track data, encrypted and encoded on the second track of every debit and credit card for every ATM WAN service provider.. Russian carders just don't want to invest in having it broken and no hackers have thought to look for the manufacturing specs when inside certain networks..
Interesting is, how many targets this smartphone tapping generates:
. Crunching just one month of N.S.A. cellphone data, a secret report said, required 120 computers and turned up 8,615,650 “actors” — apparently callers of interest. A similar run using three months of British data came up with 24,760,289 actors.
And then, when some flight coach is calling their phone, telling that he has students who only want to learn how to fly large airoplanes but not how to land them (as it was the case with the 9/11 terrorists) or if FSB is calling them that people want to visit us who formerly lived with terrorists (like the boston bombers), then the nsa notices all that, and puts this information to its haystack and does... Nothing. As they have to take notice of thousands of "similar" targets -from apps like angrybird.....
What is special is an unexpected side-effect of the support end date... The theory goes that the evil hackers will hold off releasing bots using zero-day exploits until just after the support date ends, since they then know that the hole will never be patched.
So perhaps there's a log jam of zero-day exploits just waiting to be unleashed...
Of course its unlikely that Microsoft would sit idly by if this really happened, but who knows?
It's possible that there are people sitting on exploits, but I doubt Microsoft would fix them in XP either way. XP is over 12 years old, Vista is over 7 years old, Windows 7 is over 4 years old, and now Windows 8 is over a year old, and probably next year we will have Windows 9. How many OSs do you think Microsoft wants to maintain? Even Vista is scheduled for End Of Life in just three years.
"want" has very little to do with it. It's all about reputation risk. Microsoft would really rather not catch the blame should all the ATMs in the world suddenly spit out their contents onto the street, or just sit there with a friendly BSOD.
@ Bill K
Using UDP instead of TCP is actually a good practice. UDP/IP is easy to implement with few to no vulnerabilities. The DO-178B Level A packages usually have full UDP, but only partial TCP due to complexity. Who wants that kind of complexity in kernel mode? Not me. So, I usually implement a reliable and/or secure transport on top of UDP at application layer. A UDT variant optionally with DTLS is possible here. Reduces TCB while giving most benefits of TCP with possibly an optional speed boost.
@ Steve Wildstrom
"@renke The problem, as we know from hundreds of bad examples, is that systems that are not supposed to be connected to the internet very often are."
Yes they ignore the huge risk. At least putting an embedded VPN or guard in front would help. Most embedded guys do nothing.
@ Brian M
"#2, There is nothing that makes TCP superior over UDP for security. It's up to the protocol designer to add the security, regardless of which is used."
Which Dan Kaminsky showed in recent years with his attacks on TCP mechanisms.
One simple solution might be to use these higher robustness microkernel virtualization solutions. I used to write about a bunch here. Many support virtualizing XP, have dedicated networking stacks running on top of microkernel, and have some VPN-type offering. Seems like a good interim solution for legacy XP ATM's if we can't get rid of them.
I also think eComStation's OS/2 guys are high fiving each other talking about how eventually they'll run WinXP out of "their" legacy market.
Most of these ATMs are probably unpatched as it is; I doubt ending support will make much of a difference either way. Desktop malware, on the other hand, will probably become pretty widespread, since XP is still a prevalent desktop OS. XP can be blamed for security holes as long as MS can tout how Windows 7 & 8 are unaffected. They have never had a reputation for security as it stands. Besides, ending support encourages more people to upgrade.
@ Greg A,
I suspect MS will be preasured into keeping XP going, because their "corporate customers" will black mail them into doing so.
Depending on who you belive, I've seen estimates that say as much as 70% of larger SMSEs are running XP and overall XP still has around half of business sector... The implication of this if true is that the hardware has likewise not been upgraded/replaced, and is very unlikely to be able to run later versions of MS OS's, further printers and other peripherals on such machines won't have drivers etc. Thus the cost of an upgrade is beyond the budget...
That said what I do know was Vista was a disaster, not quite as bad as ME but close, and Win8 appears to not have had much take up except on new machines sold to individuals.
But it's potential worse than that, I know of developers who still run Win2K because the debuging tools they use don't work on later MS OS's, whilst the bespoke code they produce does run on XP but not on Vista etc...
The custom proprietary protocol is nominally an International Standard, ISO 8583. The major vendor introduced some small arbitrary changes in the interest of security-by-obscurity. It is already a savagely tedious protocol to parse; none of the usual parsing metalanguages (such as ASN.1) can cope with it, because it is self-describing.
-They all put encrypted tunneling, firewalls, and IDS on their networks
-How about something actually designed for an embedded high-security network? Page guarding, write-back-hashing, modern stack+heap+ROP anti in kernel allocator, encrypted tunneling where the protocol has no encryption, PKI signed deployment of OS images with a ROM solution for dynamic loading
-hardware oracle basic configuration persistence with EC or PKI enforcement
If I was a designer I'd source a hardened TCP/IP stack for some low powered ARM platform, and then role out a better protocol and use some MAC based security model on a flash file system. Their current PHY and WAN model actually works.
I'd also change card security too. Use 4-digit pin and biometric for everything, scrap CVV which is what allows card dumps to work now.. Also don't store encrypted pin on track 2..
@Frank Wilhoit: I know. A security researcher published finding from a contract he did at some con in recent years, regarding the protocol. The networks are entirely on leased lines on all continents; some infections came in through data centers before though.
There has never been an entry to the networks found outside of ATM hardware, and not the cheap stand alone PPP ATMs either. The banks also have hidden many security issues, mostly internal breaches through bad hiring practises..
There are still businesses, and especially government offices that use Windows 98. End of life, lack of updates, massive security holes... These are things that many businesses just don't care about.
@Preston L. Bannister
Done right, old machines with old software can be entirely secure.
99% agreement. Done right, they will not be the means by which a cracker is able to crack your network.
And, done right, the measures put in place for the old systems should alert you that a cracker has cracked other systems on your network.
If at some point a haired boss in his management pool reads or hears of this missive, and panics ... you are going to cause a good guy grief. (You can bet on this.)
If there is a pointy-haired boss there then the security processes are probably already compromised.
I don't see the crackers as being that much more intelligent than their targets. But once you add in the ego of the pointy-haired bosses you end up with vulnerabilities.
The leased lines and the custom vaguely documented protocol are the only things that kept it from constant jackpotting when XP WAS supported
Yup the leased lines I was aware of ran the old CCITT X.25 standard (predates ISO OSI, and oddly the Racal Packnet version developed in Raynes Park, Surrey UK, is still in use for sending bulk SMSs..)
As for the protocol, yup it had more dialects than there are cockroaches in a New York Brown Stone. All based on ISO 8583 and it's general wierdness. You have to pay big bucks for ISO docs and you won't --or shouldn't-- find it up on the web even though they turn up as a PDF these days.
It's many years since I played with ePOS systems so my original "printed copy" in my dead tree cave is a little out of date by a couple of decades.
However you can get a feel of it from
Which should be enough to make any sensible coder look a little worried (ie the 128 bit, bitfield is a recipe for disaster). Which is possibly why nobody writes it from scratch they just steal it from somebody else ;)
As for ATMs and cryptography... I once found out the DES key used by a UK Building Soc, their security measure was to give one half to one member of staff and the other half to another member of staff in a branch. So one had to remember "1234" whilst the other had to remember "ABCD"... and if a member of staff got promoted and moved to a different branch they had a 50/50 chance of being told the other half of the key in the new branch...
There are still businesses, and especially government offices that use Windows 98. End of life, lack of updates, massive security holes...
Yes I remember reading an article --I think it was on GCN-- that fingered the US Gov for this, and another article naming the DoD and DoE as doing this on clasified networks where TS info was used...
Whilst I can believe US Gov is guilty as charged in the first article, I'd rather hope the second article was wrong...
Mind you I still have to run Win3.1 and Small-C as I wrote software on it for driving HPIB instrumens years ago and I still get asked to change it from time to time... God alone knows what's going to happen when the National Instruments PC2a interface card dies as it's silver not black screw fitted.
There is no inherent desire to have ATM machines rock solid. It is a cost factor, and the machines are insured. So its a balancing game...
"How about something actually designed for an embedded high-security network? Page guarding, write-back-hashing, modern stack+heap+ROP anti in kernel allocator, encrypted tunneling where the protocol has no encryption, PKI signed deployment of OS images with a ROM solution for dynamic loading"
I sure wasn't about to mention every specific technical feature I'd put in my solution. People's eyes would gloss over trying to read it. Strong TCB, isolation of untrusted code, transport security, logging and authenticated remote mgmt are all in the separation VMM solutions I referred to. At least three come with partitioned filesystems and networking which run outside of untrusted partition. And all support executing unmodified, insecure as can be, legacy code on WinXP. One also actively markets its architecture to banks.
Personally, I think we need a Protection Profile for ATM machines that balances functionality with security. I can think of a few options that do this while being pretty cheap. They're Linux, OpenBSD, and microkernel-based respectively. Just need to ensure the baseline is fairly strong and can be maintained by lazy ATM companies.
There's no point in migrating existing ATMs to a newer OS, because ATMs contain a bunch of custom hardware for which drivers probably only exist for embedded XP.
They aren't connected to the Internet, and if anyone who has enough knowledge to pwn them can gain physical access or MitM its communication with the bank's network, then OS patches likely won't make much difference. I bet the ATM software itself is shoddy enough that an attacker who had one to play with could fuzz it and find something exploitable.
Anyway, I expect banks will probably roll out newer OSes when they replace the ATM hardware, and not before.
Although this is primarily about ATMs, many store and restaurant POS systems use Windows. Often they display a Windows screensaver to let everyone know. Smaller businesses such as restaurants use these integrated systems to processes credit cards on unsecured lines over the internet.
A privacy worry is the possibility of state actors tracking our spending habits. After all, they're looking at our recreational activities such as WOW and Angry Birds.
> I suspect that there are many businesses who won't
> migrate off of XP even if MS gave away free copies of
> Win 6/7/8 and throw in a free copy of Office as well.
> Simply because they cann't upgrade the systems.
Windows crops up in a lot of places it should never have been, probably because that was the platform the programmers were most familiar with.
I have one client with a machine that uses a laser to cut thick steel plate. They have a 250KW generator to power it. The (new) genset and (used) laser cost in the low six figures. The CNC control software runs a customized version of Windows XP; the machine is over ten years old, and the manufacturer no longer supports it; their service department's only advice for problems is "contact our sales department for a price for a new one."
All XP is doing is loading the control program; the "custom" part is some kind of real-time kernel patch. Given there are inexpensive or free RTOS out there, the mind, she boggle.
Besides bank machines and point-of-sale terminals, I've seen XP on way more medical equipment than I'm comfortable with. I'm sure there are more copies in all sorts of industrial control applications, in hardware that's *never* going to see a different version of Windows. On the other hand, in my opinion most of those machines shouldn't be networked to start with.
Our ATMs are on a major U.S. processing network, run Windows XP (not XPe embedded), communicate via the internet, and the vendor prohibits us from applying patches or hardening the OS. This is their standard operating procedure. Also, ATMs still use 3DES for all of their external communication.
While we've been careful to only allow our ATMs to communicate via VPN, the ATM techs tell me most sites don't restrict network access to them because it makes it hard to remotely support them.
@Jonno is correct - ATMs used to be all OS/2 (and dial-up) but they switched to Windows XP because a widely deployed COTS stack is more convenient and easier to support in the field.
Also, ATMs still use 3DES for all of their external communication...the ATM techs tell me most sites don't restrict network access to them because it makes it hard to remotely support them.
--*Arms thrown up* I left out my expletives...
@ Network guy
“Our ATMs are on a major U.S. processing network, run Windows XP (not XPe embedded), communicate via the internet… ATMs still use 3DES for all of their external communication.”
Cough, a good friend of mine helped setup JPM_Chase branches in a big state. They used about five Sever 2003’s per office. The systems are supposed to be hardened – but who knows. They run everything from the impact printer, the ATM, to daily (or bi-daily sweep).
But, everything that runs through the Federal Reserve system is monitored by a number of agencies.
@Brandioch: I agree. Most sysops are exactly the kind of people that tried to hack into stuff before, just with more formal education and experience. They should be, on average, at least as skilled as their adversaries.
The advantage of hackers and script-kiddies is that they tend to have a lot more spare time on their hands and can afford to concentrate all of it on a single vulnerability. The sysop has to watch all angles of attack, and in the meantime keep the system running, upgrade/replace old components, handle stupid requests from computer-illiterate coworkers (or PHBs), etc. If you also keep in mind that management tends to view computer security as wasted money (it's always the others that get hacked...), and understaffs IT departments to the point that they can hardly keep up with maintenance, hackers (and even script kiddies) have a fighting chance.
All those copies of Windows XP are still Microsoft’s responsibility.
Remember, it never sold them, it only licensed them. It claims they are its intellectual property.
Imagine you had a piece of property that you abandoned and neglected, letting it get covered with weeds, occupied by squatters, interlopers dumping rubbish etc: the city council would prosecute you for creating a noxious neighbourhood nuisance. All those abandoned Windows XP installations come under the same principle.
After all, property is property, right?
I am having a hard time figuring out what people think makes UDP so much better than TCP, security wise.
DO-178B Level A is for real time flight systems. No internet exposure, small network, really nothing to do with security on the internet.
Sure any hypothetical UDP protocol has been exploited less than TCP because it has been used much less if all all in a security sensitive application. I was taught that a one-off solution by a small group is unlikely to be as secure as a protocol that has been used for years and worked on and tested by many. If you are adding TCP-like features back into UDP, what are the chances that your solution is more secure?
Kaminsky's TCP black arts are basically attacks against applications, not TCP itself. Or if not, which attack did I miss that indicts TCP itself?
I do wonder if it might be possible to improve tcp to do something with duplicate packets when they arrive, like make sure that they hash to the same value as the accepted packet or raise an alarm/drop the circuit. I'm sure some IDSs do that, but they are a lot harder to deploy than TCP.
UDP is simple. It does one thing. It has little state to manage. A trusted part of networking stack benefits from such traits in terms of lower defects. If app needs reliability, it can handle it itself.
If you are worried about security, neither TCP nor UDP alone are sufficient. Without authentication, either protocol is completely vulnerable to MITM. Unless your program is poorly written, the only additional danger of UDP should be the increased difficulty in mitigating DDOS attacks because of the spoofed IP address, but it's not like TCP is immune to DDOS attacks anyway.
If we are talking ATMs, I would suggest that IPSec or a VPN should be used to provide the authenticaiton and encryption.
No doubt. In my designs, UDP is a bottom layer for which I have easily understood code with long track record. From there, transport security is added at network (eg IPsec), application via proxy (SSL/SSH tunneling), or within application itself (UDT-A, SSL). The reason I promote UDP is Id rather have a UDP stack in kernel mode than a full TCP stack. Or as native code in the case of a sandboxed or interpreted application.
That the "high assurance" networking stacks available only have partial TCP support illustrates the point. The complexity made a rigorous evaluation too risky/costly. My approach leads to "pay for what you use" style. This also allows evolving a product's security over time strengthening layer by layer, from bottom up.
All that said, I think TCP subsets might work out. The DO178B stacks often do that. Ideally, any hard to analyze options would be removed. One thing Ive done (ans so did Poly2 team) was change code to just drop packet for anything not accepted, maybe log it, and ensure those TCP settings will work for apps in use. Lowers the TCB a little at least.
@ Lawrence D'Oliveiro
"Remember, it never sold them, it only licensed them. It claims they are its intellectual property.
Imagine you had a piece of property that you abandoned and neglected, letting it get covered with weeds, occupied by squatters, interlopers dumping rubbish etc: the city council would prosecute you for creating a noxious neighbourhood nuisance. All those abandoned Windows XP installations come under the same principle.
After all, property is property, right?"
Nicely worded. If I were Microsoft, I'd say to that the property had become unfit for use, that I was evicting my tenants, that I provided new property at reasonable rate to same tenants that accommodated most of their fixtures/property, and I plan to demolish the old property afterward. ;) If IP was treated like physical property, I doubt a judge would force Microsoft to maintain very dangerous properties when safer ones were available in same location.
I forgot to tell you thanks for mentioning your Fenrir protocol. I like keeping lists of projects trying to improve protocol, system, etc security. I hadn't seen that one before you mentioned it. Good luck on it.
@ Lawrence D'Oliveiro, Nick P,
Whilst it's amusing to point out Micro$haft as a "slum landlord", you have forgot the maxim of "fit for purpose", and "safety ordanaces", "property zoning", "building codes", etc etc.
XP was the fourth or fith time MS had "raised slum city, out of wood-n-tar atop a major fault line". Most US cities that burnt to the ground learnt their lesson the first time...
And anybody breaking the rules to build a new "tarpit slum" would either have been jailed or making pretty big "pay offs" to elected officials.
@Clive, Robinson, Nick P, Lawrence D'Oliveira, et alii
These "intellectual properties" of Microsoft also happen to be a major conduit for commerce. In this case they are not dissimilar to vessels using major shipping routes.
Now there's quite a body of commercial and property law concerning salvage of derelicts ... which should be interesting in this context.
A salvor gains an interest in the derelict vessel he salvages and takes out of the way of shipping: derelicts constitute a shipping hazard of the high seas. Salvage courts are a respected part of international trade.
So what should Microsoft do about all the salvors, the computer technicians, who have fixed their Piece_of_S**t_OSes_and_Apps, salvaged their reputation, and generally kept Microsoft's ship (of fools?) afloat for one more day, month, year? If the Law of Salvage is anything to go by, we have gained a sizable interest in that self-same "Intellectual Property" of Microsoft's.
I suggest Microsoft donate the source trees of their obsolete, defunct OSes and applications, under the GPL of course, to that sizable band of brothers that Microsoft has so far neglected. That might also help keep Microsoft from making those same mistakes again.
Sorry for answering late. I think the problem you have is that you think that is Eve is far away. But what if Alice, Bob and Eve are connected to the very same Switch and Bob is sleeping? Now tell me how TCP is more spoof proof than UDP in this situation.
@ Wesley Parish
Nice take with the salvage law. That would be interesting.
Far as open sourcing, they might not be able to fully do that even if they wanted to. I remember that HP said VMS couldn't be open sourced due to licensing issues with specific components of it. I can think of a few potential issues:
1. The OS contains code that belongs to someone else, licensed for use in that product.
2. Licensing and distribution deals for the OS prevent it from going to just anyone.
Of course, I think Microsoft wouldn't release source code just to ensure their dominance. Desktop Linux took forever to get where it is today. Had they had XP code, esp for hardware interfaces, Microsoft would have lost market share sooner. The last code leak of Windows also showed it was very ugly inside. They wouldn't care to let people see that either.
@ Clive Robinson
"XP was the fourth or fith time MS had "raised slum city, out of wood-n-tar atop a major fault line". Most US cities that burnt to the ground learnt their lesson the first time..."
That's funny. We can go on and on with metaphors blaming XP but we both know XP isn't the problem. There were always safer, more futureproof, etc options out there. Business's kept demanding the opposite with a particular set of requirements, often with short-term focus. Windows XP met their requirements.
The other aspect is that the code was made using tools designed for lockin. The Microsoft SDK's are incompatible with about everything else. Had they chosen POSIX with modular software, they might have had a chance at porting their stuff easily. The choice to tightly couple their software with closed source OS of a vendor known for both quality & product longevity issues is just asking for problems later. Vendors, ATM vendors in this case, did it to themselves.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.