Little Pig, Little Pig! Let Me Admin! (Security Thread)

User avatar
Friday
Posts: 6264
Joined: Mon Jan 20, 2014 7:40 pm
Location: Karma: -65373

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Friday » Fri Sep 09, 2016 10:25 pm

If you fail to defeat Rocky, he will one day enlist you in his mercenary squad.
ImageImageImage

User avatar
Mongrel
Posts: 21290
Joined: Mon Jan 20, 2014 6:28 pm
Location: There's winners and there's losers // And I'm south of that line

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Mongrel » Fri Sep 09, 2016 10:48 pm

I have no idea why, but now I'm imagining some kind of cut-and-paste magazine photo 2D animation involving a military-beret-wearing Barney Ross pushing a Rocky Katamari ball made up entirely of mercs and guns. Occasionally you recognize a face like Jason Staham or Carl Weathers.
Image

User avatar
Sharkey
Posts: 768
Joined: Mon Jan 20, 2014 6:11 pm
Location: Send Lawyers, Guns and Money
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Sharkey » Sat Sep 10, 2016 1:25 am

Make it Burgess Meredith pushing the sisyphean macho-katamari and you've got a sale.

P.S. My dad once shot himself through the hand with a nail gun and pulled it out with his teeth, but Burgess Meredith also slapped the shit out of him for being a punk when he was a kid, so Meredith is pretty much top of the totem pole of Hemingway cartoon manliness from my point of view.

P.P.S. On the macho graph I'm just sort of hovering outside the margins making great mojitos and probably fucking everybody else's wives. Which I hear is a time honored reproductive strategy.
Image

User avatar
Mongrel
Posts: 21290
Joined: Mon Jan 20, 2014 6:28 pm
Location: There's winners and there's losers // And I'm south of that line

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Mongrel » Sat Sep 10, 2016 2:08 am

Sharkey wrote:and probably fucking everybody else's wives. Which I hear is a time honored reproductive strategy.


Fun Fact: There's an actual legit official academic anthropological term for the runty skinny primates/mammals who reproduce by fucking the big guys' mates when the big guys aren't around. That term is - I shit you not - "Sneaky Fuckers".

That's not quite at the level of The Thagomizer being real, but I'd say it's right up there.
Image

User avatar
Sharkey
Posts: 768
Joined: Mon Jan 20, 2014 6:11 pm
Location: Send Lawyers, Guns and Money
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Sharkey » Sat Sep 10, 2016 2:59 pm

Long story short, this is why our dicks are mushroom shaped.
Image

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Thad » Mon Oct 03, 2016 2:11 am

Brace yourselves—source code powering potent IoT DDoSes just went public

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.

Thank Christ it's not my job to fend off DDoS attacks anymore. And my condolences to anyone whose job it currently is.

So, we've got a real problem here:

The Internet is, largely, a stack of 1970's-era protocols that have limited robustness against extremely simple brute-force attacks.

It is very difficult to upgrade these protocols to something more robust while maintaining compatibility with the billions of devices that are currently using them.

And speaking of "billions of devices", that now includes thermostats, refrigerators, cameras, etc.

And so far, the makers of those devices face no financial benefit for ensuring their software is secure, and no financial consequence if it is not.

And that includes regulatory consequences. The US government is made up of people who have neither the understanding nor the inclination to pass any sort of regulations to require device manufacturers (or website maintainers, or retail stores, or...) to secure their shit. And even if they did, odds are pretty good it would cause new problems without fixing any of the old ones.

And even if we had some kind of a silver bullet, a communications protocol that was not susceptible to DDoS attacks, the rollout would be a long and painful process. It's been eighteen years since IPv6 was standardized and fucking nobody's adopted it. As fast as the Internet itself changes and evolves, you'd be forgiven for thinking that the underlying communications technology moved at a brisk pace too. It doesn't. Since 1998 we've gone from dialup to carrying tiny supercomputers in our pockets and connecting our refrigerators to the Internet. And those phones and refrigerators are exchanging information with servers in basically the same format that those 56K modems did.

User avatar
Mothra
Woah Dangsaurus
Posts: 3963
Joined: Mon Jan 20, 2014 7:12 pm
Location: Boston, MA
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Mothra » Mon Oct 03, 2016 10:12 am

Gonna be a loooong and paaainful transition.

I look forward to the day some jagoff DDoSes the huge-ass touchscreen Starbucks coffee maker in the break room.

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Thad » Tue Oct 04, 2016 1:20 am

And of course it's not just the protocol stack that's the problem.

Ars: Unsafe at any clock speed: Linux kernel security needs a rethink

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."


The Washington Post expands on this in an article called Net of insecurity: The kernel of the argument: A rope of sand (I may have made that last part up).

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.


Of course, a lot of it is Google's fault.



Another Ars article, Copperhead OS: The startup that wants to solve Android’s woeful security has this to say:

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.


Going back to the first article: the vast majority (85%) of Android kernel bugs come from third-party hardware drivers, not the Linux kernel itself.

Torvalds and the other core Linux devs believe that they're not responsible for insecure third-party drivers, and that's a perfectly reasonable attitude. But it's a very twentieth-century one. The "make sure it performs, and then if people find any security vulnerabilities we'll patch them" approach to software design...well, as the Post noted, it's what helped get Linux where it is today. But it's not the way forward.

I don't pretend to be a tenth of the programmer Torvalds is. But I think I can clear an extremely low bar and say that I'm better at dealing with human beings than he is. And here's the point where those two things intersect: programming is all about understanding how your program is going to be used.

And here's the thing, Linus: your program is used by jackasses who don't give a fuck about security, write shitty drivers, and then never, ever update the software.

They're not going to fix their shit. So you need to build them a nice padded cell so that when they fuck up, they can't wreck up the place. No, that's not fair, but fair has nothing to do with it. You need to start looking at software from the perspective of "How badly can somebody fuck this up, and how can I make sure that when that inevitably happens, it won't do any damage?" You need to quit thinking of performance as something that you focus on at the expense of security, and start considering that if your software is not secure, then it's not performing.

...that's all I've got time for tonight. But Android's not the only OS that's fucking up Linux. Next time, I plan on talking about systemd.

User avatar
Grath
Posts: 2387
Joined: Mon Jan 20, 2014 7:34 pm

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Grath » Tue Oct 04, 2016 7:25 am

Thad wrote:Next time, I plan on talking about systemd.

I would like to personally stab whoever came up with systemd. Preferably with a knife that is somehow made out of systemd, so that it's unwieldy, bloated, and extra painful.

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Election 2016

Postby Thad » Tue Oct 04, 2016 10:10 pm

So clearly Grath already knows what systemd is. But I'll give a quick explanation for anybody who doesn't.

First, some nomenclature. Linux is a kernel, not an operating system, but people frequently say "Linux" when they mean the GNU operating system with the Linux kernel. The GNU Project has been trying to get people to call it GNU/Linux for the past couple of decades for reasons that are beyond the scope of this post. For our purposes, I'll be calling it GNU/Linux to distinguish it from Android and ChromeOS (which both use the Linux kernel but not the GNU programs and libraries).

Basically: Debian, Red Hat, Ubuntu, etc., the "Linux distributions" that people run on desktops, laptops, and servers, are GNU/Linux. Android and ChromeOS are not GNU/Linux. For embedded/IoT devices, it depends; some run Android, some run GNU/Linux, and some run something else entirely.

At any rate. There's a component of the operating system, init, that's used to launch the core parts of the OS at boot time. Prior to 2011, every GNU/Linux distribution used something called sysvinit for this purpose. The "sysv" refers to UNIX System V, released in 1983.

So yeah, sysvinit is pretty long in the tooth. It's slow, it's inefficient, it's outdated.

So in 2010, a couple of developers at Red Hat started working on systemd as a replacement for sysvinit.

That part's fine. A new, modern replacement for sysvinit is a great idea.

The idea's not the problem. The execution is. Because systemd is a bloated, insecure mess.

Instead of simply calling initialization scripts, systemd performs a bunch of other low-level OS tasks. From a 2014 Infoworld article, Systemd: Harbinger of the Linux apocalypse:

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.


But here's the thing: eventually, major software came to rely on systemd. Most notably, GNOME -- which, despite huge fragmentation, is still as close to a de facto standard desktop environment as GNU/Linux has -- now requires systemd in order to run. (BSD users are pretty pissed about this.)

So now basically every major GNU/Linux distribution uses systemd (unless you count Gentoo and Slackware as major distributions). Everyone seems to hate it, but they use it anyway because their software won't work without it.

...holy shit. That guy in high school who said Red Hat was going to become the new Microsoft was right.

So, lengthy preamble over, with systemd now (hopefully) adequately explained, we now come to this headline: How to Crash Systemd in One Tweet.

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.


Did somebody say "memory-unsafe language"? Let's talk about C. A programming language created in 1969, which reflects a 1969 approach to design: it's fast, it's efficient, and it gives the developer tremendous control over the computer's low-level functions. It is not designed to hold your hand; it is not designed to protect you from yourself. If you're doing something that is incredibly stupid, the best you can hope for is a warning message.

And most low-level OS components are still written in C, with predictable results. Which brings us to a May 2015 TechCrunch article called Death to C.

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.


And that's the thing: it doesn't have to be this way. We can change. Here's Evans again, in a recent article called Learned helplessness and the languages of DAO:

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.


He goes on to discuss formal verification, a methodology whereby, instead of evaluating security by testing, a program is written like a mathematical theorem, with every possible outcome accounted for.

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.


Prevoty is interesting. The posts are a little heavy on the marketing, but they've got substance, too; there's a good post called Signatures Are Dead, Now What? (referring to, eg, virus signatures):

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.


Anand is getting at the sort of thing I was talking about yesterday: patching vulnerabilities as they're found is a twentieth-century approach to security, and it's increasingly impractical and ineffectual (partly because there's a proliferation of network-connected devices that never install security updates, but even up-to-date software, but even when developers and IT departments follow best practices and stay on top of security updates, zero-day attacks are still a constant threat). Meanwhile, language processing is as advanced as it's ever been and getting better all the time. When data gets fed into a program, there should be a way to parse it and determine whether there's something in there that's not right -- and I'm not just talking about sanitizing inputs. The linguist in
me is fascinated by this approach, and I look forward to hearing more as it develops.

Bottom line, though, is it represents a shift from closing vulnerabilities after they're discovered to preventing them from occurring in the first place. That's where we need to go -- but see my earlier comments on just how hard it is to change entrenched technology. This is going to be a long
and painful process.

On the other hand, no amount of baked-in security is going to protect against device manufacturers leaving open Telnet ports and users not resetting default passwords.

User avatar
Mothra
Woah Dangsaurus
Posts: 3963
Joined: Mon Jan 20, 2014 7:12 pm
Location: Boston, MA
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Mothra » Wed Oct 05, 2016 2:13 am

(Post moved from Election 2016)

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Thad » Wed Oct 05, 2016 10:00 am

Thanks, Mothra!

User avatar
Büge
Posts: 5440
Joined: Mon Jan 20, 2014 6:56 pm

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Büge » Wed Oct 05, 2016 1:19 pm

Hmph.
Image

User avatar
Grath
Posts: 2387
Joined: Mon Jan 20, 2014 7:34 pm

Re: Election 2016

Postby Grath » Wed Oct 05, 2016 11:56 pm

Thad wrote:systemd rant

For further examples, click here.

My favorite one is "rm -rf / can actually BRICK YOUR FUCKING MOTHERBOARD with systemd installed"

User avatar
Mongrel
Posts: 21290
Joined: Mon Jan 20, 2014 6:28 pm
Location: There's winners and there's losers // And I'm south of that line

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Mongrel » Thu Oct 06, 2016 10:19 pm

Image

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Thad » Sat Oct 22, 2016 4:20 pm

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.


I hate it when I'm right.

Today the web was broken by countless hacked devices – your 60-second summary

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.

User avatar
Mongrel
Posts: 21290
Joined: Mon Jan 20, 2014 6:28 pm
Location: There's winners and there's losers // And I'm south of that line

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Mongrel » Tue Dec 13, 2016 12:12 am

Image

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Thad » Thu Feb 09, 2017 12:47 am

So apparently Valve just learned about sanitizing inputs and is currently patching a vulnerability where users could just stick fucking <script> tags right in their Steam profiles.

Image

User avatar
Kayma
Posts: 343
Joined: Tue Jan 21, 2014 1:40 am

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Kayma » Fri Feb 10, 2017 7:34 pm

I make it a point to add "Bobby Tables" any time I'm in a position to make user accounts.

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Little Pig, Little Pig! Let Me Admin! (Security Thread)

Postby Thad » Fri Feb 17, 2017 12:08 am

So ASLR is completely broken.

For those who don't know, that's address space layout randomization, a technique that randomizes the location at which low-level, high-privilege OS components are loaded into memory.

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."

Who is online

Users browsing this forum: No registered users and 14 guests