Slashdot Mirror
Linux Bug Leaves USA Today, Other Top Sites Vulnerable To Serious Hijacking Attacks (arstechnica.com)
Dan Goodin, reporting for Ars Technica: Computer scientists have discovered a serious Internet vulnerability that allows attackers to terminate connections between virtually any two parties and, if the connections aren't encrypted, inject malicious code or content into the parties' communications. The vulnerability resides in the design and implementation of RFC 5961, a relatively new Internet standard that's intended to prevent certain classes of hacking attacks. In fact, the protocol is designed in a way that it can easily open Internet users to so-called blind off-path attacks, in which hackers anywhere on the Internet can detect when any two parties are communicating over an active transmission control protocol connection. Attackers can go on to exploit the flaw to shut down the connection, inject malicious code or content into unencrypted data streams, and possibly degrade privacy guarantees provided by the Tor anonymity network. At the 25th Usenix Security Symposium on Wednesday, researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit that allows them to inject content into an otherwise legitimate USA Today page that asks viewers to enter their e-mail and passwords.
USENIX is scooping DEFCON?
It isn't.
And using SSL/TLS or ipsec would basically close this hole entirely. What we see here is that it might be a little easier to inject into non-ciphered non-authenticated content and there may be a slightly larger scope of attackers positioned to do it.
NON STORY
There has always been a risk that plan text traffic could be tampered with, nothing has really changed here and I don't see that risk even being significantly increased.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Do you have some examples of secure closed source? It's hard to find examples that have an install base in the server world as big as Windows or Linux, and examples of less used systems can be a bit suspect as they could simply be a statistical anomaly or not well known and not a popular target in the hacker scene. (although some of those guys will dig into pretty much anything, especially if they can work out a cool presentation at DEF CON)
Linux vulns tend to get corrected pretty quickly, as there are a lot of contributors. And like most vulns the easy way to avoid this is not to add so many damn features.
PS - OpenBSD doesn't have this flaw, and it is also open source.
“Common sense is not so common.” — Voltaire
Most ordinary users don't look at the source because they just want a computer that works and does what they want it to. However, publishing source code allows hackers to find the vulnerabilities more easily than guessing them with closed source software. Open source software is inherently insecure and closed source offers far greater security.
At the 25th Usenix Security Symposium on Wednesday, researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit that allows them to inject content into an otherwise legitimate USA Today page that asks viewers to enter their e-mail and passwords.
It looks to me that by having the source code available, these researchers - white hats - found the vulnerability before the bad guys did. Of course, USA Today being highjacked wouldn't exactly be this horrible ordeal or any real loss to humanity.
I wrote a tiny bit of IPsec code about 15+ years ago, for a router company thinking it would take off. It still hasn't taken off, and I've given up on anyone giving two shits about rolling out IPsec in any significant way.
“Common sense is not so common.” — Voltaire
The DOS possibilities are ignored by you. This is a significant problem. Why bother with a DDOS via a botnet when you can do this kind of thing from a single host?
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
The above does not seem believable — in principle. Unless by "hackers anywhere" means "hackers able to login anywhere".
Would any resident network experts care to comment?
Why is my real account disabled?
Am I the only one that (mis-)read the headline and went WTF?
However, publishing source code allows hackers to find the vulnerabilities more easily than guessing them with closed source software. Open source software is inherently insecure and closed source offers far greater security.
Ahhh yes, the unbreakable security of obscurity.
Do you publish a newsletter by any chance?
I say good riddance!
https://www.eff.org/https-everywhere
I'm not in the habit of responding to obvious trolls, but this case makes very clear the flaw in the logic of people who actually believe that open source is insecure.
The bug is in the specification, which is necessarily open in order to create inter-operable systems. And what is code, if not a machine readable specification?
The idea that closed source is more secure, taken to its logical end, is an argument for closed systems that don't inter-operate with other systems. Their operation would have to be entirely secret and proprietary.
I'm not in the habit of responding to obvious trolls, but this case makes very clear the flaw in the logic of people who actually believe that open source is insecure.
The bug is in the specification, which is necessarily open in order to create inter-operable systems. And what is code, if not a machine readable specification?
The idea that closed source is more secure, taken to its logical end, is an argument for closed systems that don't inter-operate with other systems. Their operation would have to be entirely secret and proprietary.
It really goes both ways. Open and Closed source code are equally secure. Many times open source code is though to be so secure that people don't discover the bugs for many years later. The advantage of open source is that the bug generally gets fixed faster than closed source due to the visibility of the issue.
The bug is in the RFC, which Linux implements faithfully. I find it funny that the only reason Linux is the only mainstream operating system that is vulnerable is because it's the only mainstream operating system that implements the RFC. And yes, it is a very critical bug, one which the RFC needs to address, too.
Also, the fix was committed a few weeks ago, but distributions haven't pushed it out yet (at the time the arstechnica article was written).
Go to Google images and search for anuses pictures, it's like when You're doing your makeup at the mirror, right? It's start to get clean, but I know it still is your ass face.
quit finding our back doors.
sincerely,
fbi/nsa/cia
I read the brief article, and read RFC5961, and here's a quick summary:
A TCP connection is uniquely identified by the combination of: Source IP address; Destination IP address; Source port number; Destination port number. TCP also has a sequence number, which helps reorder packets. It also helps prevent spoofing, but spoofing is still possible. Any computer on the internet can craft a packet to send to a Destination IP address and Destination port with all the other fields spoofed. A spoofer cannot receive a reply (the Destination machine will send any replies to the indicated Source IP address, which the spoofer cannot see).
So, it's possible to inject SYN and RST requests into valid streams, shutting down other people's connections (although you couldn't be sure you've succeeded). RFC5961 tries to prevent this by adding some cases where the SYN/RST are not treated as valid, but instead it sends a special ACK to the source requesting confirmation. To avoid denial of service, these special ACKs are rate-limited to 10 per 5 seconds. Note these special ACKs are only generated if the SYN or RST look "nearly" valid based on the sequence number, otherwise the RST or SYN is ignored.
And that's what they discovered is the problem--open your own connection to any Destination which has long-term connections (and they picked a USA Today website, but anything would work), and every 2 seconds try to get it to generate those special SYN/RST ACKs. If it's not under "attack", you'll get your ACKs.
Then, spoof billions of packets using a chosen source IP address (and loop through all sequence nums and port nums) and guess the dest port (say, 80).
Now send a little traffic to the Destination on your valid connection to try to get these special SYN/RST ACKs. If you don't get your ACKs (due to the global rate limiting), then you "know" that you've stumbled upon a valid combination of Source IP/port and Destination IP/port and sequence number, so you know who's talking to the Destination machine. If you've picked a Source Address and port number not connected, then these special ACKs don't get generated, so your slow traffic generating these ACKs will not be rate limited, so you can tell this Source IP/port are not connected to this destination IP/port.
So RF5961 turns a pesky annoyance bug into a bug where its possible to determine who's connecting to a particular website (although time consuming).
With more care, they then figure out the sequence number--and once you have that, you can do targeted data injection. (It's always possible to do blind data injection, but the chance you can accurately inject javascript is hard since the sequence number is hard to predict).
RFC5961 should not do global rate limiting--it leaks important data.
It's not a Linux bug, but a buggy RFC implementation. Please read TFA and then try to resume your lame trolling against OSS.
It looks to me that by having the source code available, these researchers - white hats - found the vulnerability before the bad guys did.
There is no indication in the paper that the researchers looked at the Linux source code to develop this attack. On the contrary, it looks like they designed the attack using methods devised from earlier research.
They also note that Windows, FreeBSD, and OS X are not vulnerable. In this case, being open source is not an indicator of security.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
Vulnerabilities don't grow on trees... they hide in the ground. You have to dig to find them. And source code makes vulnerabilities shallower (less effort to find).
Two words, egress filtering.
GL finding a provider that doesn't have egress filtering rules.
Nothing scary here, on to the next article.
Good luck with your "NSA implanted" protocols which never get flushed out due to obscurity and closed source.
Found the Microsoft shill. History complete invalidates this stupidity. Shocking that Microsoft is shilling so desperately in efforts to force people to Win10 nightmares.
No OS is 100% secure. No OS is invulnerable to bugs. Anyone who would assert anything close to what you've stated is a literal imbecile or a liar.
>https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/cao
Off-Path TCP Exploits: Global Rate Limit Considered Dangerous
Authors:
Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, and Srikanth V. Krishnamurthy, University of California, Riverside; Lisa M. Marvel, United States Army Research Laboratory
Abstract:
In this paper, we report a subtle yet serious side channel vulnerability (CVE-2016-5696) introduced in a recent TCP specification. The specification is faithfully implemented in Linux kernel version 3.6 (from 2012) and beyond, and affects a wide range of devices and hosts. In a nutshell, the vulnerability allows a blind off-path attacker to infer if any two arbitrary hosts on the Internet are communicating using a TCP connection. Further, if the connection is present, such an off-path attacker can also infer the TCP sequence numbers in use, from both sides of the connection; this in turn allows the attacker to cause connection termination and perform data injection attacks. We illustrate how the attack can be leveraged to disrupt or degrade the privacy guarantees of an anonymity network such as Tor, and perform web connection hijacking. Through extensive experiments, we show that the attack is fast and reliable. On average, it takes about 40 to 60 seconds to finish and the success rate is 88% to 97%. Finally, we propose changes to both the TCP specification and implementation to eliminate the root cause of the problem.
Better fix this "Linux bug" by changing TCP specification standards? No, bitches.
The title says Linux bug, this is bullshit. It is posted before they even demonstrated proof of concept later Wednesday
>researchers with the University of California at Riverside and the US Army Research Laboratory will demonstrate a proof-of-concept exploit
Over and over lately arstechnica have been quoted on Slashdot stories that have been lies. Does anybody else see this security flaw? Has anybody ever been affected by it even one time? No, they post this shit before they even demonstrate proof of concept. They call it a Linux bug yet want to change TCP/IP standards and even allude to Tor.
Slashdot is FBI. Look at the names who are reporting this Linux bug too. "Lisa from the Army and.."
gtfo.
Timeline:
arstechnica (b.s. stories lately)
FBI Slashdot claims "Linux bug"
THEN proof of concept by these people...
Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, and Srikanth V. Krishnamurthy, University of California, Riverside; Lisa M. Marvel, United States Army Research Laboratory...
@ In Austin, TX
(about Linux bug) on *USA Today and "other top sites"*... USA Today. And. Other ^^^TOP SITES^^^. naw homie.
Solution before proof of concept? Change TCP/IP standards to solve "root of problem"
Look at the names again of Riverside and US Army Research again.
Mention Tor.
They want to alter TCP/IP in any way possible to make it snoopable on Tor. Everything else is tracked by default unless you block it, and if your PC clock is set right they use timelogs.
Fuck you Slashdot. Fuck you FBI.
It has never happened, and they claim it affects Linux all the way back to 2012 .. Kernel 3.6.
So it is a never-happened exploit, nobody is going to get hacked on USA today, if you were about to have a problem on USA today... they would be patching their own shit not re-writing TCP/IP in any way shape or fashion
FBI cunts at slashdot busted again.
Call this the Linux bug that needed TCP/IP re-written in a way that saves USA Today even though nobody ever hacked shit on USA today.. according to the proof of concept to be demonstrated later today in Austin by some chinese people at Riverside and a chick named Lisa of the Army.
Get,, the... fuck,, OUT.
haaaaappy anniversary Windows 10.
Windows 10, the US Government spy shop Microsoft's latest flagship social engineering, data mining, spyware, malware, that comes FREE because ANNIVERSARY . AND.. with no start button, some ads in the "Store", no way to see what is in the security patches, keyboard logging, Indian tech support etc.
Your mama's got crabs Slashdot FBI.
Does WIndows, FreeBSD and OSX implement RFC 5961? Looks like the vulnerability lies in the specs and not in the implementation.
bullshit.
This exploit never happened. It's a ploy to modify TCP/IP.
Minus 1 Slashdot. You are FBI.
If a hacker injected a story into USAToday that was total BS, would anyone notice the difference?
When will the community finally dump this shitty operating system? Every day we hear about another 0-day exploit. Will people ever learn?!
Anything that isn't vulnerable to this one *right now*, is vulnerable to a nasty DoS based on ACKs that it is meant to stop. Obviously, it could have implemented the fixed defense... only, they didn't. Not one of the BSDs, nor Windows.
No, they don't. And they are completely vulnerable to the attack RFC 5961 is meant to avoid.
You dumb internet nigger. Keep crying! Your tears are DELICIOUS!
Do you have some examples of secure closed source?
Even if you were to get an answer to that the result would always be "but it could contain undiscovered vulnerabilities" and the same is the case with open source software despite the fact that you can see the code. Yes it does mean that white hats could find and fix bugs easier but it also means black hats could find and exploit bugs easier so whether it is more or less secure depends on who is looking at the code.
There are too many variables to ever broadly say open source or closed source is more secure and it's not something you can prove.
you are vulnerable to intensive workload so you are uselessly vulnerable? You don't even seem to know what DoS exactly is.
FreeBSD supports partial implementation of 5961. As well as one of the authors of the RFC for 5961 being a FreeBSD committer. FYI. I have yet to see a Security Advisory for FreeBSD yet about this issue. So time will tell. But so far only Linux is affected.
Vulnerabilities don't grow on trees... they hide in the ground. You have to dig to find them. And source code makes vulnerabilities shallower (less effort to find).
And less effort to fix.
Apparently Microsoft paid for the article, because its not a Linux bug. If I am not mistaken, Windows and all other TCP OSs have this problem because of the fact TCP is an insecure protocol (by itself), OF COURSE you can rewrite the packets if you are a man in the middle. This has been known for a very long time. TLS will solve this problem of course.
I don't really need the source to find and exploit bugs. There are excellent tools for picking apart binaries. High level languages are not necessarily more readable than assembler. High-level mainly is an advantage for portability, specifying data structures, and modifying. If I'm reverse engineering, I don't really need any of those features.
What is troublesome is when I don't even have access to the binaries. Pentesting is a whole different ballgame, and there are a million guys better at that aspect of hacking than I am.
Windows and Mac OS X were the only other OSs mentioned in the article and according to the article, the fix was applied to the linux kernel 4.7 three weeks ago. One good thing is that the other OSs who are still dragging their feet on implementing 5961 fully, now have a heads up.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
perhaps you'd need to read this http://www.theregister.co.uk/2...
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
No, and the vulnerability from implementing it is actually worse than doing nothing at all.
Without RFC 5961 support, an attacker with visibility of your communication can DoS it with forged resets. With RFC 5961, an attacker without direct visibility can determine if two hosts are communicating and then tamper with the data---roughly 80% of the time, according to paper.
The RFC process follows essentially the same many-eyes approach, yet this vulnerability went undiscovered from draft to implementation.
Open vs closed development of specs and software had little or no effect on the end result---although with open software you could remove the offending code yourself if the developer is unwilling to change or remove it himself.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
And allows for quick fixes.
This attack has already been mitigated in linux kernels 4.0 and later. It sets a per socket limit for creating challenge acks which makes it much harder to hit the challenge ack limit that is used to get side channel information. 3.6 to 3.9 are vulnerable but you can turn it off easily just set the sysctl for tcp_challenge_ack_limit to 0. That prevents any challenges being sent, effectively denying them access to the side-channel and giving you as system that is no more vulnerable than a kernel previous to 3.6.
I don't really need the source to find and exploit bugs.
Well, it sure helps!
The partial implementation in FreedBSD is identified as not vulnerable. It's on p 15 of the research paper.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
DoS vs data manipulation, which is worse?
And the manipulation can include closing the connection anyway so more like "DoS" vs "manipulation and DoS"
I will take my TCP stack without RFC5961, please and thank you
Not a Linux bug. Same thing will work against Windows, and everything else. It's in the RFC that everyone follows.
Wrong. Kernel 4.7 has effective mitigation without disabling rate limit on challenge acks.
The title of the article is WRONG. USA Today and most major sites are NOT vulnerable to this. If you did not notice, the video is from Match 22. The vulnerability fix was reported by the research group in July and patched upstream by the Linux kernel community shortly thereafter. USA Today and other sites were fixed ahead of this announcement back in July. Read more on this at blogs.akamai.com.
What are you complaining about? Like the headline says, the bug left the USA today!
Il n'y a pas de Planet B.