Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)
Posted: Fri Sep 09, 2016 10:25 pm
If you fail to defeat Rocky, he will one day enlist you in his mercenary squad.
Hold on to your butts.
https://brontoforum.us/
Sharkey wrote:and probably fucking everybody else's wives. Which I hear is a time honored reproductive strategy.
J.M. Porup wrote:The Linux kernel today faces an unprecedented safety crisis. Much like when Ralph Nader famously told the American public that their cars were "unsafe at any speed" back in 1965, numerous security developers told the 2016 Linux Security Summit in Toronto that the operating system needs a total rethink to keep it fit for purpose.
[...]
"Cars were designed to run but not to fail," Kees Cook, head of the Linux Kernel Self Protection Project, and a Google employee working on the future of IoT security, said at the summit. "Very comfortable while you're going down the road, but as soon as you crashed, everybody died."
"That's not acceptable anymore," he added, "and in a similar fashion the Linux kernel needs to deal with attacks in a manner where it actually is expecting them and actually handles gracefully in some fashion the fact that it's being attacked."
Craig Timberg wrote:But while Linux is fast, flexible and free, a growing chorus of critics warn that it has security weaknesses that could be fixed but haven’t been. Worse, as Internet security has surged as a subject of international concern, Torvalds has engaged in an occasionally profane standoff with experts on the subject. One group he has dismissed as “masturbating monkeys.” In blasting the security features produced by another group, he said in a public post, “Please just kill yourself now. The world would be a better place.”
There are legitimate philosophical differences amid the harsh words. Linux has thrived in part because of Torvalds’s relentless focus on performance and reliability, both of which could suffer if more security features were added. Linux works on almost any chip in the world and is famously stable as it manages the demands of many programs at once, allowing computers to hum along for years at a time without rebooting.
Yet even among Linux’s many fans there is growing unease about vulnerabilities in the operating system’s most basic, foundational elements — housed in something called “the kernel,” which Torvalds has personally managed since its creation in 1991. Even more so, there is concern that Torvalds’s approach to security is too passive, bordering on indifferent.
“Linus doesn’t take security seriously; it’s yet another concern in his mind, and he’s surrounded himself with people who share those views,” said Daniel Micay, a Toronto-based security researcher whose company, Copperhead, is developing a hardened version of the Android mobile operating system, which is based on Linux. “There are a lot of kernel developers who do really care about security, but they’re not the ones making the calls.”
The rift between Torvalds and security experts is a particular source of worry for those who see Linux becoming the dominant operating system at a time when technology is blurring the borders between the online and offline worlds. Much as Windows long was the standard for personal computers, Linux runs on most of the Internet’s servers. It also operates on medical equipment, sensitive databases and computers on many kinds of vehicles, including tiny drones and warships.
“If you don’t treat security like a religious fanatic, you are going to be hurt like you can’t imagine. And Linus never took seriously the religious fanaticism around security,” said Dave Aitel, a former National Security Agency research scientist and founder of Immunity, a Florida-based security company.
J.M. Porup wrote:Google did a deal with the devil for market share, says [ACLU Speech, Privacy, and Technology Project principal technologist Chris] Soghoian, who has described the current parlous state of Android security as a
human rights issue. By giving Original Equipment Manufacturers (OEMs) and wireless carriers control over the end-user experience, Google allowed handset manufacturers to find ways to differentiate their products, and wireless carriers to disable features they thought would threaten their business model.
Thad wrote:Next time, I plan on talking about systemd.
Paul Venezia wrote:While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.
No matter which side of the argument you're on, this monolithic approach is in violation of the rules of Unix, specifically the rule stating it's best to have small tools that do one job perfectly rather than one large tool that is mediocre at performing many jobs. Prior to this, all the functions subsumed by systemd were accomplished by assembling small tools in such a way that they performed the desired function. These same tools could be used within a variety of other scripts to perform myriad tasks -- there was no singular way to do anything, which allowed for extreme freedom to address and fix problems. It also allowed for poor implementations of some functions, simply because they were poorly assembled. You can't have both, after all.
That's not the end of the story. There's more happening with systemd than many might realize. First, systemd is rather inelegantly designed. While there are many defensible aspects of systemd, other aspects boggle the mind. Not the least of these was that, as of a few months ago, trying to debug the kernel from the boot line would cause the system to crash. This was because of systemd's voracious logging and the fact that systemd responds to the "debug" flag on the kernel boot line -- a flag meant for the kernel, not anything else. That, straight up, is a bug.
However, the systemd developers didn't see it that way and actively fought with those experiencing the problem.
Andrew Ayer wrote:The following command, when run as any user, will crash systemd:Code: Select all
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
After running this command, PID 1 [process ID 1, the init process] is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that's short enough to fit in a Tweet.
[...]
The immediate question raised by this bug is what kind of quality assurance process would allow such a simple bug to exist for over two years (it was introduced in systemd 209). Isn't the empty string an obvious test case? One would hope that PID 1, the most important userspace process, would have
better quality assurance than this.
[...]
Systemd's problems run far deeper than this one bug. Systemd is defective by design. Writing bug-free software is extremely difficult. Even good programmers would inevitably introduce bugs into a project of the scale and complexity of systemd. However, good programmers recognize the difficulty of writing bug-free software and understand the importance of designing software in a way that minimizes the likelihood of bugs or at least reduces their impact. The systemd developers understand none of this, opting to cram an enormous amount of unnecessary complexity into PID 1, which runs as root and is written in a memory-unsafe language.
Jon Evans wrote:If you write code in C, you have to be careful not to introduce subtle bugs that can turn into massive security holes — and as anyone who ever wrote software knows, you cannot be perfectly careful all of the time.
[...]
Buffer overflows and dangling pointers lead to catastrophic security holes, again and again and again, just like yesteryear, just like all the years of yore. We fail to learn. Heartbleed. GHOST. The Android 4.3 KeyStore. Etcetera, etcetera, etcetera.
C was and is magnificent, in its way. But we cannot afford its gargantuan, gaping security blind spots any more. It’s long past time to retire and replace it with another language.
The trouble is, most modern languages don’t even try to replace C. They’re vastly more abstract. They’re easier to read. They provide programming constructs which are enormously powerful if you’re dealing with vast quantities of data, or multiple concurrent threads and processes, or distributed systems. But they’re not good at the thing C does best: getting down to the bare metal and working at mach speed.
…Which is why I’m so interested in Rust. It’s the one new programming language that might, finally, at last, replace C and C++ — and Rust 1.0 finally went into beta last month. To quote Steve Klabnik:Historically, programming languages have had a tradeoff: you can have a language which is safe, but you give up control, or you can have a language with control, but it is unsafe. C++ falls into that latter category. More modern C++ is significantly more safe than it used to be, but there are fundamental aspects of C++ which make it impossible to ever be truly safe. Rust attempts to give you a language with 100% control, yet be absolutely safe.
Jon Evans wrote:Everything is terrible. Most software, even critical system software, is insecure Swiss cheese held together with duct tape, bubble wrap, and bobby pins. See eg this week’s darkly funny post “How to Crash Systemd in One Tweet.” But it’s not just systemd, not just Linux, not just software; the whole industry is at fault. We have taught ourselves, wrongly, that there is no alternative.
[...]
Everything is terrible because the fundamental tools we use are, still, so flawed that when used they inevitably craft terrible things. This applies to software ranging from low-level components like systemd, to the cameras and other IoT devices recently press-ganged into massive DDoS attacks [...] to high-level science-fictional abstractions like the $150 million Ethereum DAO catastrophe. Almost all software has been bug-ridden and insecure for so long that we have grown to think that this is the natural state of code. This learned helplessness is not correct.
Everything does not have to be terrible.
Jon Evans wrote:In principle, code can be proved correct with formal verification. This is a very difficult, time-consuming, and not-always-realistic thing to do; but when you’re talking about critical
software, built for the long term, that conducts the operation of many millions of machines, or the investment of many millions of dollars, you should probably at least consider it.
Less painful and rigorous, and hence more promising, is the langsec initiative:The Language-theoretic approach (LANGSEC) regards the Internet insecurity epidemic as a consequence of ad hoc programming of input handling at all layers of network stacks, and in other kinds of software stacks. LANGSEC posits that the only path to trustworthy software that
takes untrusted inputs is treating all valid or expected inputs as a formal language, and the respective input-handling routines as a recognizer for that language.
…which is moving steadily into the real world, and none too soon, via vectors such as the French security company Prevoty.
Kunal Anand wrote:[...] a lot of today’s defenses rely on pattern matching – regular expressions, signatures, black lists, virtual patching – and as there is a high cognitive load to maintaining these things it means a lot of updating, yet lists are out of date the minute they are implemented. Security professionals will be tasked with figuring out how to keep track of different firewalls, different configurations and different rules for different properties. Unfortunately, despite this effort it is
trivial for fuzzers to go right through solutions like regular expressions.
[...]
The majority of today’s firewalls have to run thousands of patterns to match for known attacks, and false positives and false negatives run high, so it is difficult to determine what is normal. These sorts of traditional methods rely on code that is constantly changing. When you are trying to
detect something that’s always changing, due to the fact that the application is constantly changing, it causes solutions to be out of date as soon as they are created. What does this mean?
It is time to learn a new security language.
Language Theoretic Security (LANGSEC) treats code patterns and data formats as languages and checks their grammars for the purpose of preventing the introduction of malicious code into software. It is able to recognize an attack even if it has never been seen before and will deal with it appropriately without the risk of any false positives.
Thad wrote:systemd rant
Thad wrote:Hey guys, remember 2004? Major hole in IE6, entire Internet slowed down noticeably?
If 2016 wasn't the worst year for overall stability since '04, it's about to be.
Chris Williams wrote:Compromised machines, following orders from as-yet unknown masterminds, threw massive amounts of junk traffic at servers operated by US-based Dyn, which provides DNS services for websites large and small.
The result: big names including GitHub, Twitter, Reddit, Netflix, AirBnb and so on, were among hundreds of websites rendered inaccessible to millions of people around the world for several hours today.
Now, researchers have devised an attack that could spell the end of ASLR as the world knows it now. The attack uses simple JavaScript code to identify the memory addresses where system and application components are loaded. When combined with attack code that exploits vulnerabilities in browsers or operating systems, the JavaScript can reliably eliminate virtually all of the protection ASLR provides. The technique, which exploits what's known as a side channel in the memory cache of all widely used modern CPUs, is described in a research paper published on Wednesday.
[...]
AnC works by using what's known as an EVICT+TIME cache attack that detects which memory locations are accessed by a CPU's MMU. The researchers identified 22 microarchitectures from Intel, Advanced Micro Devices, and ARM that were vulnerable. They went on to say they have yet to test an architecture that didn't provide the MMU signal necessary to exploit the side channel.
[...]
Given how crucial caching is to the performance of modern CPUs, the researchers say architectural fixes are likely to be too costly to be feasible. And even if hardware mitigations are possible—say, by creating a separate cache for page tables—the researchers warn that the vulnerability may resurface in software. They conclude their findings with a recommendation that's sure to get the attention of software developers everywhere:
"We hence recommend ASLR to no longer be trusted as a first line of defense against memory error attacks and for future defenses not to rely on it as a pivotal building block."