Home Tags Datagram

Tag: Datagram

Linux kernel gets patch for 11-year-old local-root-hole security bug

DCCP code cockup lay unnoticed since 2005 Eleven years ago or thereabouts, the Linux kernel got support for the Datagram Congestion Control Protocol – and also got a privilege escalation bug that has just been fixed.…

In the three years since IETF said pervasive monitoring is an...

IETF Security director Stephen Farrell offers a report card on evolving defences FEATURE After three years of work on making the Internet more secure, the Internet Engineering Task Force (IETF) still faces bottlenecks: ordinary peoples' perception of risk, sysadmins worried about how to manage encrypted networks, and – more even than state snooping – an advertising-heavy 'net business model that relies on collecting as much information as possible. In a wide-ranging 45-minute, 4,000-word interview (full transcript in this PDF), IETF Security Area Director Stephen Farrell gave a report card of what's happened since the Internet Architecture Board declared that “pervasive monitoring is an attack”, in RFC 7258. Much of the discussion used Farrell's presentation to the NORDUnet conference in September, and the slides are here. Let's boil the ocean, so we can cook an elephant.

And eat it. Given the sheer scale of the effort involved – the IETF's list of RFCs passed the 8,000 mark in November – nobody expected the world to get a private Internet quickly, but Farrell told The Register some of the key in-IETF efforts have progressed well: its UTA (Using TLS in Applications), DPRIVE (DNS Privacy), and TCPINC (TCP INCreased security, which among other things is working to revive the tcpcrypt proposal rejected earlier in the decade). UTA: The idea is to get rid of the nasty surprises that happen when someone realises a standard (and therefore code written to that standard) still references a “laggard” protocol – so, for example, nobody gets burned complying with a standard that happens to reference a deprecated SSL or TLS standard. “The UTA working group produced RFC 7525 (Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), https://tools.ietf.org/html/rfc7525 here).

The last time I looked, there were something like 50 RFCs that are referencing that [The Register checked this list, provided by Farrell – it seems to be close to 70 already].” The idea of UTA is that a protocol written 10 or 15 years ago should be updated so it no longer references the then-current version of TLS, he said. “That's being used in order to provide a common reference: as people update their implementations, they'll reference a more modern version of TLS, currently TLS 1.2, and as TLS 1.3 is finished, we have an automated-ish way of getting those updates percolating through to the documentation sets. “That's quite successful, I think, because it normalises and updates and modernises a bunch of recommendations.” DNSPRIV: Readers will recall that IETF 97 was the venue for the launch of Stubby, a demonstrator for securing DNS queries from the user to their DNS responder. Stubby, a demonstrator of DNS privacy work That, Farrell said, is a good example of where DNSPRIV is at – on the user side, it's ready for experimental code to go into service. “DNS privacy is something that is ready to experiment with.

The current work in DPRIVE was how to [secure] the hop between and the next DNS provider you talk to. “That's an easy problem to tackle – you talk to that DNS resolver a lot, and you have some shared space, so the overhead of doing the crypto stuff is nowhere.” Getting upstream to where DNS queries become recursive – your ISP can't answer, so they pass the query upwards – is much harder, he said. “Assuming that [the ISP] needs to find “where is theregister.co.uk?”, he'll eventually talk to the UK ccTLD, and then he'll go talk to .co.uk and then he'll go talk to theregister.co.uk – it's forking the communications a lot more, and it's a little harder to see how to efficiently amortise the crypto. “The DPRIVE working group are now examining whether they think they can produce some technology that will work for that part of the problem.” TCPINC: Some of the questions in this working group may never be seen by ordinary Internet users, but they're still important, Farrell said. “I think we're close to having some TCP-crypt-based RFCs issued, there's been code for that all along. Whether or not we'll get much deployment of that, we'll see.” “I think there are a bunch of applications that maybe wouldn't be visible to the general public. Let's say you have an application server that has to run over a socket – an application that runs on top of the Linux kernel, say, where you have to use the kernel because of the interfaces involved, and you can't provide the security above the kernel because you need it inside. “That's where TCPINC fits in.
Storage – they have really complex interfaces between the network-available storage server and the kernel, and there's lots of complex distributed processing going on.” That's important to “the likes of NetApp and EMC and so on”, he said: “For some of those folks, being able to slot in security inside the kernel, with TCPINC, is attractive.
Some, I might expect, will adopt that sort of thing – but it may never be seen on the public Internet.” Security and the end-to-end model Farrell said more encryption is changing the Internet in ways the general public probably doesn't think about – but which they'll appreciate. The old end-to-end model – the “neutral Internet” – has been under both overt and covert attack for years: carriers want to be more than passive bit-pipes, so they look for ways that traffic management can become a revenue stream; while advertisers want access to traffic in transit so they can capture information and inject advertisements. Ubiquitous encryption changes both of these models, by re-empowering the endpoints.

Along the way, perhaps surprisingly, Farrell sees this as something that can make innovation on the Internet more democratic. He cited HTML2 and QUIC as important non-IETF examples: “there's a whole bunch of people motivated to use TLS almost ubiquitously, not only because they care about privacy, but because of performance: it moves the point of control back towards the endpoint, not the middle of the network. “One of the interesting and fun things of trying to improve the security properties and privacy properties of the network is that it changes who controls what. “If you encrypt a session, nobody in the middle can do something like inject advertising. “It reasserts the end-to-end argument in a pretty strong way.
If you do the crypto right, then the middlebox can't jump in and modify things – at least not without being detectable.” He argues that the carrier's / network operators' “middleboxes” became an innovation roadblock. “The real downside of having middleboxes doing things is that they kind of freeze what you're doing, and prevent you innovating. “One of the reasons people did HTTP2 implementations, that only ever talk ciphertext, is because they found a lot of middleboxes would break the connection if they saw anything that wasn't HTTP 1.1. “In other words, the cleartext had the effect that the middleboxes, that were frozen in time, would prevent the edges from innovating. Once they encrypted the HTTP2 traffic, the middleboxes were willing to say 'it's TLS so I won't go near it', and the innovation can kick off again at the edges.” Won't somebody think of the sysadmin? Systems administrators – in enterprises as well as in carriers – are less in love with crypto. “Network management people have been used to managing cleartext networks,” he said. For more than 20 years, for perfectly legitimate reasons – and without betraying their users – sysadmins would look into packets, see what they contained, and when sensible do something about them. “Not for nefarious reasons – in order to detect attacks, in order to optimise traffic, and so on. We're changing that, and that also means the technology they're using will be undergoing change, to deal with much more ciphertext than plaintext. “We need to learn better ways of how to fulfil those same functions on the network,” he said. “If you had some security mechanism in your network for detecting some malware attack traffic, instead of being able to operate that from the middle of the network, it pushes a requirement on you to move that to the edge.” Commercial services are starting to understand how this can work, he said: “If you look at some of the commercial instant messaging providers, that have introduced end-to-end encryption of their messaging – they have found they can move those functions in their networks to new places to do what they need to do. “It means change, but it doesn't make network management impossible.” Advertising models will change Companies collaborating to collect advertising data remains a big challenge, he said.

That's likely to change – “there's no reason why a particular business model has to last forever”, but in the meantime, “it's hard to see how we make a dramatic improvement in privacy. “We can make some improvements, but how we make it dramatically better – it's hard.

The incentives are aligned to make all the service providers want to be privacy-unfriendly, from the point of “me”, but not perhaps the point of view of 99 per cent of people who use the Internet, and seem happy enough with it.” Breaches and leaks are frightening the service providers, which helps, because providers “realise that storing everything, forever, is toxic, and in the end they'll get caught by it.” About the cough NSA coughThe Register also asked: what protects future standards against security organisations polluting standards, as they did with DUAL-EC? “As an open organisation, we need to be open to technical contributions from anywhere,” Farrell said, “be that an employee of the NSA, or be that – as we've had in one case – a teenager from the Ukraine who was commenting on RFCs five or six years ago.” It has to be handled socially, rather than by process, he argued, citing the IETF's creation of the Crypto Forum Research Group, chaired by Alexey Melnikov and Kenny Paterson and designed to bring together IETF standards authors and the academic crypto community. He described it as a “lightweight process” designed to assess crypto proposals – have they been reviewed? Is the proposal novel and maybe not ready for prime time? “The number of NSA employees that attend IETF [meetings] – I don't think it's a useful metric at all.
I think how well peoples' contributions are examined is a much more useful metric, and there, things like having the CFRG, having academic cryptographers interacting much more with the standards community – those are more effective ways of doing that. “We've set up a thing called the Advanced Networking Research Prize, which is a prize for already-published academic work.
It pays for the academic come to an IETF meeting, give us a talk, get them involved” (Paterson first became involved in the CRFG as an invited academic who won the prize). Spooks want to monitor everyone because they believe everyone might be guilty, he added, and that's a mistake. “We should not think people are guilty by association.

That's a fallacy – if you believe that NSA employees are not allowed to contribute, you're making the same mistake they're making.” ®

Time is running out for NTP

There are two types of open source projects: those with corporate sponsorship and those that fall under the “labor of love” category.

Actually, there’s a third variety: projects that get some support but have to keep looking ahead for the next sponsor. Some open source projects are so widely used that if anything goes wrong, everyone feels the ripple effects. OpenSSL is one such project; when the Heartbleed flaw was discovered in the open source cryptography library, organizations scrambled to identify and fix all their vulnerable networking devices and software. Network Time Protocol (NTP) arguably plays as critical a role in modern computing, if not more; the open source protocol is used to synchronize clocks on servers and devices to make sure they all have the same time. Yet, the fact remains that NTP is woefully underfunded and undersupported. NTP is more than 30 years old—it may be the oldest codebase running on the internet.

Despite some hiccups, it continues to work well.

But the project’s future is uncertain because the number of volunteer contributors has shrunk, and there’s too much work for one person—principal maintainer Harlan Stenn—to handle. When there is limited support, the project has to pick and choose what tasks it can afford to complete, which slows down maintenance and stifles innovation. “NTF’s NTP project remains severely underfunded,” the project team wrote in a recent security advisory. “Google was unable to sponsor us this year, and currently, the Linux Foundation’s Core Internet Initiative only supports Harlan for about 25 percent of his hours per week and is restricted to NTP development only.” Last year, the Linux Foundation renewed its financial commitment to NTP for another year via the Core Infrastructure Initiative, but it isn’t enough. The absence of a sponsor has a direct impact on the project. One of the vulnerabilities addressed in the recently released ntp-4.2.8p9 update was originally reported to the project back in June.
In September, the researcher who discovered the flaw, which could be exploited with a single, malformed packet, asked for a status update because 80 days had passed since his initial report.

As the vulnerability had already existed for more than 100 days, Magnus Studman was concerned that more delays gave “people with bad intentions” more chances to also find it. Stenn’s response was blunt. “Reality bites—we remain severely under-resourced for the work that needs to be done. You can yell at us about it, and/or you can work to help us, and/or you can work to get others to help us,” he wrote. Researchers are reporting security issues, but there aren’t enough developers to help Stenn fix them, test the patches, and document the changes.

The Linux Foundation’s CII support doesn’t cover the work on new initiatives, such as the Network Time Security (NTS) and the General Timestamp API, or on standards and best practices work currently underway.

The initial support from CII covers “support for developers as well as infrastructure support.” NTS, currently in draft version with the Internet Engineering Task Force (IETF), would give administrators a way to add security to NTP, as it would secure time synchronization.

The mechanism uses Datagram Transport Layer Security (DTLS) to provide cryptographic security for NTP.

The General Timestamp API would develop a new time-stamp format containing more information than date and time, which would be more useful.

The goal is to also develop an efficient and portable library API to use those time stamps. Open source projects and initiatives struggle to keep going when there isn’t enough support, sponsorship, financial aid, and manpower.

This is why open source security projects frequently struggle to gain traction among organizations. Organizations don’t want to wind up relying on a project when future support is uncertain.
In a perfect world, open source projects that are critical parts of core infrastructure should have permanent funding. NTP is buried so deeply in the infrastructure that practically everyone reaps the project’s benefits for free. NTP needs more than simply maintaining the codebase, fixing bugs, and improving the software. Without help, the future of the project remains uncertain. NTP—or the Network Time Foundation established to run the project—should not have to struggle to find corporate sponsors and donors. “If accurate, secure time is important to you or your organization, help us help you: Donate today or become a member,” NTP’s project team wrote.

Researchers tag new brace of bugs in NTP, but they’re fixable

Party like it's 1985 1955 2015 WHAT DATE IS IT ANYWAY? Back in January, Cisco dropped a bunch of NTP (network time protocol) patches; now, it's emerged that the research behind that round of fixes also turned up other bugs that haven't yet been fixed. This week, Ciscoans Matt Gundy and Jonathan Gardner teamed up with Boston University's Aanchal Malhotra, Mayank Varia, Haydn Kennedy and Sharon Goldberg to show off a bunch of possible attacks against NTP's datagram protocol. The bad news: the group reckons millions of IP addresses are currently vulnerable. The good news? The protocol is fixable, and the researchers urge the IETF to adopt a cryptographic model for better client/server NTP protocols. Fooling around with NTP is a handy attack vector, since you can spoil cryptographic calculations, “roll back time”, or cause denial-of-service attacks. A lot of attacks against NTP are man-in-the-middle attacks; what the Cisco / Boston University demonstrate are three off-path attacks (one of which, CVE-2015-8138, was fixed by Cisco in January, and has also been fixed in later versions of the NTP daemon). The vulnerabilities exist because RFC 5905, which defines NTP, has a fundamental problem: “client/server mode and symmetric mode have conflicting security requirements; meanwhile, RFC5905 suggests identical processing for incoming packets of both modes”. Vulnerabilities discussed in the paper include: A low-rate denial-of-service attack against the NTP daemon's “interleaved mode” (supposed to make timestamps more accurate); and Timeshifting attacks that haven't yet been fixed. However, because these are protocol vulnerabilities, the researchers fixing NTP is more important.

They propose replacing the current model with one that uses more cryptography. While the 'net's druids contemplate that proposal, the group reminds sysadmins they should “Finally, we suggest the firewalls and ntpd clients block all incoming NTP control queries from unwanted IPs”. ®

How one rent-a-botnet army of cameras, DVRs caused Internet chaos

Enlarge / We're also mad you're connected to the Internet, toaster et al.Disney reader comments 25 Share this story Welcome to the Internet of Evil Things.

The attack that disrupted much of the Internet on October 21 is still being teased apart by investigators, but evidence thus far points to multiple "botnets" of Internet-connected gadgets being responsible for blocking access to the Domain Name Service (DNS) infrastructure at DNS provider Dyn. Most of these botnets—coordinated armies of compromised devices that sent malicious network traffic to their targets—were controlled by Mirai, a self-spreading malware for Internet of Things (IoT) devices. But other systems not matching the signature of Mirai were also involved in the coordinated attack on Dyn. "We believe that there might be one or more additional botnets involved in these attacks," Dale Drew, CSO of Level 3 Communications, told Ars. "This could mean that they are 'renting' several different botnets to launch an attack against a specific victim, in which multiple other sites have been impacted." The motive may have been blackmail, since the attacker sought a payout by Dyn to stop.

But Drew warned that the huge disruption caused by the attack "could result in large copycat attacks, and [a] higher [number of] victim payouts [so] as to not be impacted in the same way.
It could also be a signal that the bad guy is using multiple botnets in order to better avoid detection since they are not orchestrating the attack from a single botnet source." Mirai has played smaller roles in previous attacks.
It factored into last month’s extended distributed denial of service (DDoS) attack on the website of information security reporter Brian Krebs and an even larger DDoS against the French cloud provider OVH. Mirai clearly was the star of the attack on Dyn, apparently controlling multiple groups of bots. But even in the midst of the Dyn attack, some of the Mirai-infected devices were being used to attack another target—the infrastructure of a gaming company, according to Allison Nixon, the director of security research at security company Flashpoint. That idea matches up with what others who had some insight into the attack have told Ars confidentially—that it was also pointed at Sony’s PlayStation Network, which uses Dyn as a name service provider. For now, it's not clear that the attacks on Dyn and the PlayStation Network were connected.

And with a criminal investigation underway, a Dyn spokesperson declined to confirm or deny that Sony was also a target. "We are continuing to work closely with the law enforcement community to determine the root cause of the events that occurred during the DDoS attacks last Friday," Adam Coughlin, Dyn’s director of corporate communications, told Ars. "Since this is an ongoing investigation, we cannot speculate on these events." Regardless of the reasons behind it, the attack on Dyn further demonstrates the potential disruptive power of the millions of poorly protected IoT devices.

These items can be easily turned into a platform for attacking anything from individual websites to core parts of the Internet's infrastructure.

And Mirai has demonstrated that it doesn't take "zero-day" bugs to make it happen; attackers only need poorly implemented security on devices that can't be easily fixed. From tiny cameras, mighty botnets grow Mirai is hardly the first IoT botnet to make headlines.
In December 2014, LizardSquad's "stresser" service—built on compromised home Wi-Fi routers—announced that it was ready for business with Christmas attacks on the PlayStation Network and Microsoft's Xbox Live service. (The service was eventually hacked itself.) And while Mirai played a supporting role in the 620-gigabit per second attack on Krebs on Security and the 1.5 terabit-per-second attack on OVH, those attacks also leveraged Bashlight, another (larger at the time) IoT botnet.

By the time it was over, more than 30,000 Internet-connected surveillance cameras and DVRs were involved in the OVH attack.
It lasted for over a week. There are a few things that make Mirai stand out from previous IoT botnets.

First and foremost, its code has been published openly on the Internet. On September 30, in the wake of the attacks on OVH and Krebs, someone claiming to be the malware's author published the botnet and command and control (C&C) server code on Hacker Forums.
Suddenly, anyone could access step-by-step instructions for its configuration and use. The post to Hacker Forums that started it all. On the plus side, the published source code gives researchers a great deal of insight into how Mirai operates. On the downside, however, it makes it possible for anyone who can compile the code and has access to Internet-connected servers to build their own botnet.

This opportunity provides more ambitious botnet builders a proven platform to improve upon. The simplicity of Mirai's C&C structure makes scaling it up relatively simple. "One of the things we noticed during the Dyn attack was that the C&C domain would change its address," Nixon explained. "That way, the C&C network could segment its botnet." By simply changing a DNS entry, the attacker could use the same domain to create and operate multiple separate botnets simultaneously. When a Mirai bot is created, it sends a request to the Domain Name Service for the "A" address of a domain configured by its creator. Once it has the Internet address associated with that "A" address, it locks onto that IP address. "When one C&C server fills up, [the botnet operator] can just change the IP address associated with that 'A' name," Nixon explained. New bots will connect to the new address while older bots continue to communicate with the previously labeled server. While this scheme can cause problems with resiliency of the botnet—if a C&C server gets identified and its traffic is shut down, the bots fail—it's not a big problem for the botnet long-term.

The botnet can easily be re-established from another server by simply re-discovering vulnerable devices. Checking for open doors Still, the worst thing about Mirai is that it leverages the horrible security decisions made by a handful of manufacturers of Internet-connected devices.

And despite growing public alarm, these IoT devices and their shortcomings will likely persist on the Internet for years.

A majority of the devices compromised by Mirai connect to the Internet via firmware from one company: the Chinese electronics supplier XiongMai Technologies.

The attack led XiongMai to issue a recall for some of its products sold in the US, Fortune reports. The reason XiongMai's firmware is such an easy target for Mirai is that it includes a setup interface that is essentially a hard-coded "backdoor"—an unchangeable administrative username and password, common across entire lines of devices. While the user can set their own credentials, the default credentials are hard-coded into the firmware. Mirai simply uses a hard-coded library of default usernames and passwords to log in to the devices it discovers.

This is the equivalent of walking through a parking lot, checking for unlocked car doors, and finding the keys sitting on the driver’s seat.

These devices included Panasonic printers, SNC and ZTE routers, and dozens of network-connected cameras and digital video recorders.
Some of these passwords were simply factory-set defaults, but others were permanent—meaning they could not be changed by their owners. Some of the passwords hard-coded into Mirai. Types of attacks programmed into Mirai's bots. To be compromised by Mirai, a device also had to be on a network with very weak firewall configurations (or no firewall at all).

An analysis of the botnet's code by Ars revealed that Mirai uses Telnet and SSH—the channels used to connect to a system remotely and log in to a text command prompt—to compromise and control devices. While home routers generally can be configured to block connections from outside the local network from Telnet and SSH, these connections are often left open by default. In a statement issued on October 24, a XiongMai spokesperson wrote, "XiongMai closed the Telnet port on related products before April 2015.

Therefore, for the product in April 2015 after, the hacker is simply no way to use the port to attack, and for products produced before April 2015, XiongMai has provided a firmware upgrade, [and] if [users are] really worried about the risk, it can be solved by upgrading." The spokesperson claimed that even if the patch was not applied, there would be no harm to the device by hacking attempts. Using Telnet or HTTP traffic—which is unencrypted—makes it relatively easy to catch Mirai botnet traffic with deep packet inspection.

Flashpoint had visibility into one of the botnets attacking Dyn, Nixon said, and while others had described the attack on Dyn as coming in two or three waves, "it was more like every once in a while, I would see another line of attack instructions coming in.
I had seen something like 20 or 30 lines of commands." Mirai is loaded with a variety of configurable attacks, executed in response to those command lines: Two types of UDP (User Datagram Protocol) flood attacks intended to overwhelm a target with raw network traffic (one "generic" attack with various payload options and another "plain" attack "optimized for speed") A UDP attack tailored for taking down Valve game servers by overwhelming them with queries for game connections TCP (Transmission Control Protocol) attacks based on successive SYN (synchronize) or ACK (acknowledge) floods—attacks that use TCP's "three way handshake" against the target by fooling its network interface into dedicating resources to spoofed connections GRE (Generic Routing Encapsulation) attacks that use the Cisco-designed tunneling protocol to get Internet Protocol (IP) and Ethernet packet floods past hardware used to block DDoS attacks "Proxy knockback connection," apparently for going after Minecraft servers An HTTP Layer 7 flood attack focused specifically on taking down Web servers Also in the mix is a "DNS Water Torture" attack—a UDP-based attack designed specifically to target domain name servers.
It creates DNS requests targeting a specific domain, adding random strings of text to it formatted at subdomains.
It also randomly selects the path for those requests to take, selecting from four different public DNS providers (including Google’s public DNS).

The random string—which is used as the name of a subdomain or host in a lookup request sent to the DNS server—forced the DNS service pinged to send a request to Dyn, and it forced Dyn’s servers to do a fresh look-up for each.

The requests, laundered through legitimate DNS services, looked like legitimate pass-along requests and were less easily screened out. The tale of the traffic Level 3's Drew provided Ars with a record of observed traffic as part of the DDoS against Dyn.

The first plot shows the attack traffic last Friday "compared to a typical day for this same IP space," Drew explained.

The vast majority of the attacks were largely SYN flood attacks against DYN's DNS and the "DNS Water Torture" prefix label attack, according to Level 3's data. Level 3 traffic plot showing traffic to Dyn's segment of Internet address space on October 21 (in blue) vs. a normal day (in red). A chart showing periods when the attacks against Dyn were coming largely from non-Mirai botnets. "There are two distinct attack waves," Drew said. "The first begins at 1110 to ~1310 UTC and the second (even bigger attack) begins around 1550 and goes hard for about an hour, then dropping significantly in volume.

As can be seen, there were a few smaller attacks in between the two major waves, but each was short-lived.

This is important because it shows that the bad guy is using multiple botnet networks to launch his attack." Eventually, the server that Flashpoint was monitoring began to have connectivity issues.

Then, it "may have died a serious death," Nixon noted. "It was having intermittent issues late in the day," said Zach Wikholm, a security developer at Flashpoint. "And at some point, we couldn’t get to it any more.
It died at different times for different places." That may have been indicative of network owners blocking the communications of the C&C servers once they were identified. The new normal Mirai's creator may have simply released the code because he or she had already moved on to another, better alternative. Using the screen name “Anna-senpai," the alleged author complained that because Internet service providers began shutting down traffic on protocols used to spread the malware after the attack on the Krebs site, it was getting harder to build massive armies of bots. “With Mirai, I usually pull max 380k bots from Telnet alone,” the author wrote in the post to Hacker Forums. “However, after the Kreb DDoS, ISPs been slowly shutting down and cleaning up their act.

Today, [the] max pull is about 300k bots and dropping.” After the Dyn attack, more network providers are bound to take measures to block the sort of traffic associated with Mirai.

But it will likely be years before devices vulnerable to Mirai are either properly protected from attack or removed from service.

And while consumer device manufacturers have become generally more serious about IoT security, there are still a vast number of devices on the Internet that are configured with default or permanent passwords—passwords that another botnet developer could easily add to a targeted library. Now that the potential of Mirai has been demonstrated, plenty of people will be ready to try.

And just as many are eager to take credit. Wikileaks urged its "supporters to stop taking down the US internet," saying they had "proved point".

And someone calling themselves the "New World Hackers" claimed responsibility on Twitter for the attack, posting: Just having a little fun.

Annual power test!#NwHackers — New World Hackers (@NewWorldHacking) October 21, 2016 And then they announced their "retirement", saying that they were done with DDoS attacks, adding "PS Wikileaks is a good friend."

RHBA-2016:1231-1: kernel bug fix update

Updated kernel packages that fix several bugs are now available for Red HatEnterprise Linux 6.7 Extended Update Support. The kernel packages contain the Linux kernel, the core of any Linux operatingsystem.This update fixes the following bugs:* Due to a race condition, an ipv6_txoptions corruption previously appeared whensending a UDP datagram over the IPv6 protocol.

An upstream patch has beenapplied to prevent data corruption that led to kernel panic. (BZ#1322705)* Existing Intel eXtensible Host Controller Interface (xHCI) controllers requirea delay of one millisecond after setting the CMD_RESET bit in the commandregister, before accessing any Host Controller (HC) registers.

This allows theHC to complete the reset operation and be ready for HC register access. However,when booting the xhci_hcd driver, the system could previously hang.

As aworkaround, the provided patch rescinds the mentioned delay, which minimizes therisk of system hang on boot. (BZ#1323055)* Due to a spinlock being taken twice, a deadlock previously appeared in the NFSclient or Remote Procedure Call (RPC).

The provided patch fixes thenfs_wb_page_cancel() function, and the aforementioned deadlock no longer occurs.(BZ#1324377)* Previously, the kernel did not handle properly multiple iTCO devices on IntelXeon v2, and thus the following error message was returned:sysfs: cannot create duplicate filename '/bus/platform/devices/iTCO_wdt'With this patchset, unique sysfs files and devices are created for each iTCOwatchdog device and multi-PCH support for Intel systems is included.

As aresult, the aforementioned error message is no longer logged in the kernelsyslog. (BZ#1328551)* When "read" and "write" operations received the NFS4ERR_BAD_STATEID error, theNFSv4.0 client previously attempted to recover by sending another "open" requestfor the file, making stateid recovery enter an infinite loop and the NFSv4.0client became unresponsive.

The provided patch fixes the above which caused theNFSv4.0 client to become unresponsive. Now, the NFSv4.0 client works as expectedin the described scenario. (BZ#1330561)* When a transparent proxy application was running and the number of establishedconnections on the computer exceeded one million, unrelated processes, such ascurl or ssh, were unable to bind to a local IP on the box to initiate aconnection.

The provided patch fixes the cooperation of theREUSEADDR/NOREUSEADDR socket option, and thus prevents the local port from beingexhausted.

As a result, the aforementioned bug no longer occurs in the describedscenario. (BZ#1333570)* Previously, packets including the Common IP Security Option (CIPSO) label tagtype 5 with certain category ranges were not set correctly.

As a consequence,these packets were interpreted with the fallback security label.

The providedpatch fixes the netlbl_secattr_catmap_setrng() function, and thus fixes thisbug. (BZ#1333578)Users of kernel are advised to upgrade to this updated package, which fixesthese bugs.

The system must be rebooted for this update to take effect. Red Hat Enterprise Linux Server EUS (v. 6.7.z) SRPMS: kernel-2.6.32-573.30.1.el6.src.rpm     MD5: bb530da01183f3c00c363168acda5759SHA-256: 34b3508d4b53d4ffa624682b1fab0b48baca813dbfa84bc71daa8aca419b3d96   IA-32: kernel-2.6.32-573.30.1.el6.i686.rpm     MD5: a66f76313936e081fb24212b4b653773SHA-256: fa88d829cf50c43d32dcb7314df9af3ecfd21a0cc3246dc2d4f6435b6cef37cb kernel-abi-whitelists-2.6.32-573.30.1.el6.noarch.rpm     MD5: da39e0cacb0516d3936f1fc420de5dd7SHA-256: c969cda1f8606a05279a8274b034359023f9123cd3f45d4fe9401f4669b67b14 kernel-debug-2.6.32-573.30.1.el6.i686.rpm     MD5: 5d627fa30281309c761dea44927220e6SHA-256: 6787868b3fb9c9f60d7d18aee2f173f80cfc0431a4b8a3ba0c152bb78069a165 kernel-debug-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: 465215534cb8769738b28b0a967ebf7eSHA-256: ee14518c183e421ff8a4a9dd4ef03ad56bc387f4e79f5dfb906a66dc58bdcfcc kernel-debug-devel-2.6.32-573.30.1.el6.i686.rpm     MD5: bb5b6423a861eb422308f38e268db3d2SHA-256: c3ad8cd09d2388ec6090f81948cb9f92ffa5d4c976431604525f41d973413bbd kernel-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: eada1883c03e054cb483f9ca4a473c99SHA-256: 165d7700f3015b299630b556b635024fbe9912cb2ee254d87bee913578be8ca7 kernel-debuginfo-common-i686-2.6.32-573.30.1.el6.i686.rpm     MD5: 590be04ba77c98a28d7e19048ab46486SHA-256: 0ce0cf9d9058110be4a0202c514302e36aa9c1a007a1bbe248f1bc65f728b5be kernel-devel-2.6.32-573.30.1.el6.i686.rpm     MD5: 34f587be0bb07e0c4891814f88ab9819SHA-256: 42b52074ca6d3054ff3ac91cae14c03dae1e000b7a67cba6c10e9de59ec9cc45 kernel-doc-2.6.32-573.30.1.el6.noarch.rpm     MD5: 5b1f7207ceb25b788b3f5457e8814dffSHA-256: fcd3f9f6d2d9e20434ae6c4895a3a2591f63165cc1d13c1620c7cba5c23792c2 kernel-firmware-2.6.32-573.30.1.el6.noarch.rpm     MD5: 136a5ef62309a2bb3c482f070775eb0cSHA-256: 5dda915927f9467e2dd2509f89d159be1ce1945d805fecd582f56dd9dea17199 kernel-headers-2.6.32-573.30.1.el6.i686.rpm     MD5: 177c8bfc8313d5e4178a12c22c30df5aSHA-256: ed50d97e5b257bd9c21c398f21e928a35eb88c18143833bfec931b800c3da277 perf-2.6.32-573.30.1.el6.i686.rpm     MD5: ec835fcd3314d6c8d3492811577bd371SHA-256: 626b032e92c610c01dac72105d389248ed9c89fc3bcce3ac780a6c6dc64d1417 perf-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: fbd62594e347ae042038ae7015d3a130SHA-256: 7835f4bb6d3c8a7bf247a24e97845bc67ef6659959c4f4c3b1dfec6d94e03b84 python-perf-2.6.32-573.30.1.el6.i686.rpm     MD5: 1fd38e0ad064abd43201229c857a8e5dSHA-256: 506e242c6abaed10ae591b4714e39b3963f00197ceb4b5b62ebacc2e578a3d1c python-perf-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: 71695a8dd5d69199b9ceb037ffe6b531SHA-256: 33e6342cd70d314bc4bcc09ad11b5d00df95b0c550d8bfcb8736a991c092075f   PPC: kernel-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 261e01dc64f2a6e348a5f319eb24695cSHA-256: 58c784f37a404d8f56de50080aca819e1efef0f2a3c7bf953896f84d242cbfc5 kernel-abi-whitelists-2.6.32-573.30.1.el6.noarch.rpm     MD5: da39e0cacb0516d3936f1fc420de5dd7SHA-256: c969cda1f8606a05279a8274b034359023f9123cd3f45d4fe9401f4669b67b14 kernel-bootwrapper-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 91f421f7d674e7d6186dbedc665770e4SHA-256: 56e7b3432d8e95684660e4aad615e13c74e2934e33b98b5db39577ed49894513 kernel-debug-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 9cb7d6c29d37268747dc30245f57028bSHA-256: 5b19c5d8610d5d95bd219d2406e8d150a97962745687dc42c0a44a12f1c0cd50 kernel-debug-debuginfo-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 7e9bb91ff159709376c62a75a196f8ffSHA-256: c436fc41952fc2969ff515f58e4c78ceab9da3f1b48e93bc317264cf3e78b3f3 kernel-debug-devel-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 1d880e9df21b241a77cf3cc3c61c5044SHA-256: b5c387b7b5fdc905e7c03e5cbc24e6f74be88aa9a0fd60fc6d9a0a072cc47812 kernel-debuginfo-2.6.32-573.30.1.el6.ppc64.rpm     MD5: a16ba859f4b40d520f3b3d3853a2aca8SHA-256: 428368c5498f6dd01752bc3b889ace16bb66ce9130641202760f9d3f630c61d5 kernel-debuginfo-common-ppc64-2.6.32-573.30.1.el6.ppc64.rpm     MD5: a5ddc764bf27f7a4c182702425646ed7SHA-256: b00ce0afb2ba940084d19de55dadf1fa890085688265bf0bd8f633fbc3a7a7ad kernel-devel-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 3aef109824c1ddddb4fdd2dea6b323d6SHA-256: fc63232cf555ec4f6ee9a3c9c7248c126d1ec1525419c449ec660af559a29b45 kernel-doc-2.6.32-573.30.1.el6.noarch.rpm     MD5: 5b1f7207ceb25b788b3f5457e8814dffSHA-256: fcd3f9f6d2d9e20434ae6c4895a3a2591f63165cc1d13c1620c7cba5c23792c2 kernel-firmware-2.6.32-573.30.1.el6.noarch.rpm     MD5: 136a5ef62309a2bb3c482f070775eb0cSHA-256: 5dda915927f9467e2dd2509f89d159be1ce1945d805fecd582f56dd9dea17199 kernel-headers-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 238368c5506c04403dbc03bd1362ded7SHA-256: 95729b89ffd556817b9cc0bbf2f7368e020eaafd9306f58f9226d93e0a329af1 perf-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 2ab6405b7ae9d20881caa94c970a2647SHA-256: 275a9e14e2def0a61d20fd1a9f0847afbd1aef312cf1231accc796ca926958c1 perf-debuginfo-2.6.32-573.30.1.el6.ppc64.rpm     MD5: f6c9dc03acd1e973d1cf2dcec1066ddbSHA-256: fcec81f4b3c09877a734029124983d96e7faae40faded397566e566204ce2c92 python-perf-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 7d120a9ece8d3fbd2ed599f87c1051acSHA-256: 6e2ea24da747f0d013c6101e719f07a11b48f475abc91cf23ba6a5adaf40145d python-perf-debuginfo-2.6.32-573.30.1.el6.ppc64.rpm     MD5: 488d8298e80bc8a7cbb6314f06048ccdSHA-256: 9f677ce83a28fba5f57a4c749d672daa0fe3d6769a5f0f772e87ad941ac9210c   s390x: kernel-2.6.32-573.30.1.el6.s390x.rpm     MD5: f16503fb06715466f14f9686b3574f64SHA-256: e0a22ae51bcbbab5dde46d26232a552cc37bb25b0ed36f71d32490f27accd17c kernel-abi-whitelists-2.6.32-573.30.1.el6.noarch.rpm     MD5: da39e0cacb0516d3936f1fc420de5dd7SHA-256: c969cda1f8606a05279a8274b034359023f9123cd3f45d4fe9401f4669b67b14 kernel-debug-2.6.32-573.30.1.el6.s390x.rpm     MD5: 48424be6b482cc980a156dfbce1ba2c6SHA-256: 3aac7506b63057f988ec6149f74619dcd3027742fb20b8313e498c19fe88fcc5 kernel-debug-debuginfo-2.6.32-573.30.1.el6.s390x.rpm     MD5: f71fbd6776ff649a294942cef735f495SHA-256: 03b213323809a0567d55ec92f274f2e8346a50f9dfcfc47ebdea4f66f19d491e kernel-debug-devel-2.6.32-573.30.1.el6.s390x.rpm     MD5: 39b6e3ec807e6ff6aec11259cbfb052cSHA-256: acf36a1d324fec87435c564acf3f95b6400d41475a113f5a19f28b8c0bd7c11b kernel-debuginfo-2.6.32-573.30.1.el6.s390x.rpm     MD5: 1f97b7d81251ab22d83d6569faa73529SHA-256: 30bf62db6d6483209a654cf697997186ec53b5333f470195c4cd8ecdb69074c7 kernel-debuginfo-common-s390x-2.6.32-573.30.1.el6.s390x.rpm     MD5: c3343afb371897e942791de37c77c62cSHA-256: 2658eca90b3a535eb13c5af5bce0cc6dae11bd8c059a2de8429154368fcd72ba kernel-devel-2.6.32-573.30.1.el6.s390x.rpm     MD5: 8dfcb87a8e59d7f715562d18ff4095bbSHA-256: 1aa8716c3cf44fbff3a2a012469f2fd635afec1943cb68bf8db74babde2406d8 kernel-doc-2.6.32-573.30.1.el6.noarch.rpm     MD5: 5b1f7207ceb25b788b3f5457e8814dffSHA-256: fcd3f9f6d2d9e20434ae6c4895a3a2591f63165cc1d13c1620c7cba5c23792c2 kernel-firmware-2.6.32-573.30.1.el6.noarch.rpm     MD5: 136a5ef62309a2bb3c482f070775eb0cSHA-256: 5dda915927f9467e2dd2509f89d159be1ce1945d805fecd582f56dd9dea17199 kernel-headers-2.6.32-573.30.1.el6.s390x.rpm     MD5: bbbe00d51c8deaef375bb678391aab91SHA-256: d9b59b564dc3a34daa7fa9d257ece203f476139a850766fa56b2a865fa2d1b9c kernel-kdump-2.6.32-573.30.1.el6.s390x.rpm     MD5: 468475672ed355d8ed1d2c6fc9fee156SHA-256: 231bbb2cce624cc3dda487febe5a9049ca9eba02124cc5b0f1b47ad8d7cd926c kernel-kdump-debuginfo-2.6.32-573.30.1.el6.s390x.rpm     MD5: 0776a6b036a55ba94ae5e7ce7a5fbc97SHA-256: 98148a489e8b30afbd3b5a0b7b2d56588247f44e5b085c19686c2c2201f75f38 kernel-kdump-devel-2.6.32-573.30.1.el6.s390x.rpm     MD5: af769c80b0aabff800dea4013c50288fSHA-256: 1de34ee868ee0f640ddc1f0793962093989bec2229f4a140cb853fbb42b0a4cb perf-2.6.32-573.30.1.el6.s390x.rpm     MD5: cae32466027f42254004926c2a7fd960SHA-256: fb33918ad6bc24776949c873d78bb802dccc02a0395df75bcb1c52aa475e518e perf-debuginfo-2.6.32-573.30.1.el6.s390x.rpm     MD5: 77b8cbc0cb388242236cdc65689a1145SHA-256: 5fbda28d24e07bf06890eb93d791b7bba5b1100dc3c34524f8ac17e0cb78c2fd python-perf-2.6.32-573.30.1.el6.s390x.rpm     MD5: fd8665ac4d1a537f1bbe5e8acedb0b4cSHA-256: 8bbc1da2ce93ab1aac923f4fa58dd73da131db0e2611ab2e0dec34a5fa49aea7 python-perf-debuginfo-2.6.32-573.30.1.el6.s390x.rpm     MD5: 4e44df8d893075c81550106557dbf148SHA-256: 884071b1218beaf45155664ad9e8c03890eb0de95fce0c6c16beb2e27c6388d0   x86_64: kernel-2.6.32-573.30.1.el6.x86_64.rpm     MD5: 962a024c0cb6d81c24f8b23f694c279eSHA-256: e0221c32f5643e7180ceadec0b5fa73af86c2ffd4621e40280357afb6c8c44d1 kernel-abi-whitelists-2.6.32-573.30.1.el6.noarch.rpm     MD5: da39e0cacb0516d3936f1fc420de5dd7SHA-256: c969cda1f8606a05279a8274b034359023f9123cd3f45d4fe9401f4669b67b14 kernel-debug-2.6.32-573.30.1.el6.x86_64.rpm     MD5: a728019c26a84df3c7c2756546708f2aSHA-256: 43a14776f151a3c8aa85386dfb440bd6af4e3b89d68101b001dd8d73e82355e1 kernel-debug-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: 465215534cb8769738b28b0a967ebf7eSHA-256: ee14518c183e421ff8a4a9dd4ef03ad56bc387f4e79f5dfb906a66dc58bdcfcc kernel-debug-debuginfo-2.6.32-573.30.1.el6.x86_64.rpm     MD5: d3cbdfc84b42d149b242b31f01a1fb67SHA-256: 2a812f3b0e84fb6a566c27b93ce4ea490f73ac6c25a858665b2565298a3f1a9b kernel-debug-devel-2.6.32-573.30.1.el6.i686.rpm     MD5: bb5b6423a861eb422308f38e268db3d2SHA-256: c3ad8cd09d2388ec6090f81948cb9f92ffa5d4c976431604525f41d973413bbd kernel-debug-devel-2.6.32-573.30.1.el6.x86_64.rpm     MD5: da5274de5f0d0cbc36baac6da12407e9SHA-256: 52cf4e777270c1842aeeaff634e9f1e6ef33cb75d2480a630a1ac99ef29967ba kernel-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: eada1883c03e054cb483f9ca4a473c99SHA-256: 165d7700f3015b299630b556b635024fbe9912cb2ee254d87bee913578be8ca7 kernel-debuginfo-2.6.32-573.30.1.el6.x86_64.rpm     MD5: eb94f45f9b495f8b39ce283578ca894aSHA-256: 4041673d569779803cf52134aceb551ce140b45c40599cb4444edc62125f86ab kernel-debuginfo-common-i686-2.6.32-573.30.1.el6.i686.rpm     MD5: 590be04ba77c98a28d7e19048ab46486SHA-256: 0ce0cf9d9058110be4a0202c514302e36aa9c1a007a1bbe248f1bc65f728b5be kernel-debuginfo-common-x86_64-2.6.32-573.30.1.el6.x86_64.rpm     MD5: 8641999c1a37ed9c64da1559d6b10f71SHA-256: e80f29bbb4d02efdbe3a9f3f0d91a23654dc62d6adfa210e97ecb938d6c73d00 kernel-devel-2.6.32-573.30.1.el6.x86_64.rpm     MD5: 70391c64e6538b61cc6797f0190270b5SHA-256: 05b8eb90c16326f0c98a496704f544ef64f2aa7022a742bd18892997c4bbae23 kernel-doc-2.6.32-573.30.1.el6.noarch.rpm     MD5: 5b1f7207ceb25b788b3f5457e8814dffSHA-256: fcd3f9f6d2d9e20434ae6c4895a3a2591f63165cc1d13c1620c7cba5c23792c2 kernel-firmware-2.6.32-573.30.1.el6.noarch.rpm     MD5: 136a5ef62309a2bb3c482f070775eb0cSHA-256: 5dda915927f9467e2dd2509f89d159be1ce1945d805fecd582f56dd9dea17199 kernel-headers-2.6.32-573.30.1.el6.x86_64.rpm     MD5: b8b896c092ffed0c23de610c484c7de2SHA-256: bde0f0f2a1c54464f3d31b92a47fa2cd5ca95e649bb7388ae95b7265b0948206 perf-2.6.32-573.30.1.el6.x86_64.rpm     MD5: b925a723d84008056c25a1d89c47a3dbSHA-256: 11e973884aaabb7f5d88bec2b8efda90742dbe5c3e6a7f251ce9991671fa1b79 perf-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: fbd62594e347ae042038ae7015d3a130SHA-256: 7835f4bb6d3c8a7bf247a24e97845bc67ef6659959c4f4c3b1dfec6d94e03b84 perf-debuginfo-2.6.32-573.30.1.el6.x86_64.rpm     MD5: fa7c1a01abb24461db899f233c865f01SHA-256: 2f421b6547f3cd99a5a3d5a9dfac2aa956b2484e6325590814774f31eb153aab python-perf-2.6.32-573.30.1.el6.x86_64.rpm     MD5: dc9f1034cc41494200a26286dbea3a7fSHA-256: 34d78786d4532030045cb1167d45fe0a9374b344de5ee779b954a42f427ed0a2 python-perf-debuginfo-2.6.32-573.30.1.el6.i686.rpm     MD5: 71695a8dd5d69199b9ceb037ffe6b531SHA-256: 33e6342cd70d314bc4bcc09ad11b5d00df95b0c550d8bfcb8736a991c092075f python-perf-debuginfo-2.6.32-573.30.1.el6.x86_64.rpm     MD5: 9b8017dfc1c3d2aa012ad64820ab683eSHA-256: ca6e5c34edee678dc1e0c77b57ba47fed5a41610ec29f669fe969480f45c1838   (The unlinked packages above are only available from the Red Hat Network) These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from: