• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Xbox Ones get viruses?

SPDIF

Member
There are plenty of sandbox escapes that don't rely on JIT, and IE doesn't have a particularly strong sandbox anyway. I mean, it's ok, it's just not great. My first idea would be to try to exploit their HTML5 video code.

Edit: Seems I wasn't the only one with this idea. Proof of concept in Firefox: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8643

Ok, I assume it's just on my end, but that link you're posting isn't loading correctly for me. All I can see is "Vulnerability Summary for CVE-2014-8643". Anyway, I'm just going to assume that somewhere along the way that that exploit relies on Win32. Would I be correct? Would I also be correct in assuming that somewhere along the way it relies on a file download? If so, then once again the exploit is kind of useless. The Xbox app platform just doesn't run Win32 code (at least not in the traditional sense). The browser on the XB1 also point blank refuses to download any file whatsoever. So again, bearing in mind I can't view the details of this exploit, I have no idea how this code would even be able run in the first place.
 

SPDIF

Member
Anyway, it's getting pretty late in my part of the world, and I'm very tired. So if you respond and I don't it'll be because I'm sleeping.

Double post, but who really cares :)
 

Syriel

Member
Did you bother reading the article at all?

It can have an effect. I don't know if any games are currently coded to take an advantage, but to say "it does nothing" is flat out wrong.

If you're going to be a smartass, you really should make sure the person you're making fun of is actually wrong. ;)

No, I didn't read the article because I didn't need to. I've spoken to the developers before who worked with the system and it was made clear that all of the changes were at the code level.

It's a trade-off. Games can use the extra cycles at the expense of not using the Kinect, but they have to be coded to use it. It is not automatic. Unplugging the Kinect doesn't magically make all games run better. Plugged or unplugged has zero effect.

The original statement that you posted was incorrect. I assumed that you didn't know anything about the subject and had read a bad write-up, so I corrected it.

That said, if you DO bother to look at the article you linked, you'll find this at the end of the page:

cnet said:
Update at 10:40 a.m. PT: Clarified that unplugging Kinect from current Xbox One consoles does not yield a performance boost; developers must optimize current and future games for the performance boost using Microsoft's soon-to-be-released SDK.

Perhaps the next time you source an article, you should actually read the whole thing, rather than just skimming the headline.

If you had bothered to read your own source, you would have seen that it agrees with what I posted and contradicts what you claimed.
 
If a website runs a script that serves a bogus pop-up window telling you there is a problem, along with changing the default start-up page so that you ALWAYS see that message, even after you close it and restart the Xbox, I could see how someone could confuse that for a virus. What we are really talking about though, is a browser hijacking. I still think it's pretty sad if true. Microsoft has the worst reputation when it comes to browser security.
 
Ok, I assume it's just on my end, but that link you're posting isn't loading correctly for me. All I can see is "Vulnerability Summary for CVE-2014-8643". Anyway, I'm just going to assume that somewhere along the way that that exploit relies on Win32. Would I be correct? Would I also be correct in assuming that somewhere along the way it relies on a file download? If so, then once again the exploit is kind of useless. The Xbox app platform just doesn't run Win32 code (at least not in the traditional sense). The browser on the XB1 also point blank refuses to download any file whatsoever. So again, bearing in mind I can't view the details of this exploit, I have no idea how this code would even be able run in the first place.
That particular page doesn't have many details, but you can google the CVE number.

It doesn't rely on downloading anything, it only relies on being able to play video in the browser. So you load a page with a carefully constructed, malformed video and boom. Of course that's in Firefox, so not really applicable, but the point is just that h.264 is a viable attack surface for a sandbox escape.

The exploit relies on the implementation of the codec to be buggy, but an h.264 codec for example is a huge attack surface. There's a reason so many exploits show up in flash plugins or pdf plugins, because you get this huge binary file to put your payload in, and the code to process them is very complex. So you just have to tickle the right bug or find the right ROP-chain by giving it malformed input.

Anyway, the tl;dr is that there's always a way. Sandboxes are nice, but they're not the last word in defense., just google "sandbox escape". There's a whole class of bugs whose entire purpose is to break out of a sandbox. No JIT reduces the attack surface, but not to 0.
 

SPDIF

Member
That particular page doesn't have many details, but you can google the CVE number.

It doesn't rely on downloading anything, it only relies on being able to play video in the browser. So you load a page with a carefully constructed, malformed video and boom. Of course that's in Firefox, so not really applicable, but the point is just that h.264 is a viable attack surface for a sandbox escape.

The exploit relies on the implementation of the codec to be buggy, but an h.264 codec for example is a huge attack surface. There's a reason so many exploits show up in flash plugins or pdf plugins, because you get this huge binary file to put your payload in, and the code to process them is very complex. So you just have to tickle the right bug or find the right ROP-chain by giving it malformed input.

Anyway, the tl;dr is that there's always a way. Sandboxes are nice, but they're not the last word in defense., just google "sandbox escape". There's a whole class of bugs whose entire purpose is to break out of a sandbox. No JIT reduces the attack surface, but not to 0.

Ok, maybe I'm missing something. We'll see.

For the "boom" to take place, I assume it must have to have some interaction with the underlying OS, right? And to do this, considering that it was designed for Windows, this means interacting with the native Win32 APIs, yes? If so, how do you think it would do that considering that the entire app platform for the XB1 is WinRT based? And even completely ignoring that issue for a moment, we still have the issue of needing any code that's executed to be digitally signed by MS, do we not?

Now just to be clear I don't necessarily disagree that there's always a way. If someone really wanted to dedicated their time to doing it, I'm sure they'd find a way eventually, but I'd imagine it would probaby require some sort physical interaction with the hardware (USB exploit, somehow modifying the firmware with the BD drive etc..). In which case who cares if there's a virus running on your Xbox, if you've managed to let it be physically accessed you've got bigger issues to deal with.

If a website runs a script that serves a bogus pop-up window telling you there is a problem, along with changing the default start-up page so that you ALWAYS see that message, even after you close it and restart the Xbox, I could see how someone could confuse that for a virus. What we are really talking about though, is a browser hijacking. I still think it's pretty sad if true. Microsoft has the worst reputation when it comes to browser security.

And with good reason. Thankfully they're a lot better nowadays. You could even make a case for them being the best, but I'll leave that argument for another day.
 
Ok, maybe I'm missing something. We'll see.

For the "boom" to take place, I assume it must have to have some interaction with the underlying OS, right? And to do this, considering that it was designed for Windows, this means interacting with the native Win32 APIs, yes? If so, how do you think it would do that considering that the entire app platform for the XB1 is WinRT based? And even completely ignoring that issue for a moment, we still have the issue of needing any code that's executed to be digitally signed by MS, do we not?
You only need a loadable executable module to be digitally signed. That's the point of an exploit. You trick a piece of code that is already signed, already passed all the security checks, and already has access to the necessary APIs to jump to a location that contains your code. Your code can now run with all the same privileges as the approved code. A buffer overflow for example relies on giving some piece of code an input, say a video file. The decoder (which is signed, privileged, etc) encounters something it didn't expect, but constructed in such a way that the decoder continues executing code at a location of the attacker's choosing.

You can chain exploits together, as well. Some of the most complicated can escape through multiple layers of security by using this kind of technique to get privilege escalation once, then use another exploit to escape another level, etc.
 

system11

Member
I'm fully expecting this to become a thing in future, that's why I'm not touching the PS4 web browser, the XB1 would scare me a lot more.
 

Piggus

Member
I'm fully expecting this to become a thing in future, that's why I'm not touching the PS4 web browser, the XB1 would scare me a lot more.

That's a really irrational fear. You realize that any code that impacts the way the system functions would have to be signed and approved by Sony, right? And that even IF someone found a way around that, unless you're visiting some REALLY shady sites, how would you get such a thing on your system? YouTube? Lol you don't get a virus just from browsing the Internet.

Look up how viruses work and put your mind to rest. Even on Android devices, which can run unsigned code like a PC, viruses aren't a big problem. Have you ever heard of a virus on a non-jailbroken iphone? No? Well that's because it only runs signed code.
 

SPDIF

Member
You only need a loadable executable module to be digitally signed. That's the point of an exploit. You trick a piece of code that is already signed, already passed all the security checks, and already has access to the necessary APIs to jump to a location that contains your code. Your code can now run with all the same privileges as the approved code.

Of course, you're completely right about that. Just disregard what I said about the code signing, I was still thinking about exploits that execute from a downloaded file for some reason. So anyway, final point of contention:

Let's say that you've created a piece of malware that works by exploiting a BO somewhere in IE. A BO that you've somehow discovered and successfully tested without ever seeing the stack or any other debug info, since I doubt it's as easy to get as just attaching your favourite Windows debugger. Then the only question that remains is, how? Because as I've brought up on numerous occasions now, and I don't think you've addressed it yet, we're still running on the WinRT APIs. It's all well and good saying you'll smash out of the sandbox, but how can you when the only (kind of relevant) exploit example you've found is Win32 based?

I guess it just again comes back to the theoretical of "well I'm sure someone will eventually find a way". But I don't want theory, I want POCs :) If all you want to say is that, in theory, an Xbox could get a virus, then yes, I'm sure it can. In actual practice though, I really, really doubt that it will ever happen. Which is why throughout this thread I've been so adamant that the Xbox can't get viruses. It's not that in theory it can't, it's just in actuality it won't.

Anyway, this will be my last post in this thread. It seems pointless to randomly bump it every few hours just to reply to one another. You're more than welcome to reply to me, but any reply I make to you will be through a PM.
 

Dash Kappei

Not actually that important
Why would it be via PMs?
It's not off-topic and it's interesting to read for everyone's interested in this thread's discussion.
It's a public message-board, unless for private matters one shouldn't resort to private messaging, imo.
 
Why would it be via PMs?
It's not off-topic and it's interesting to read for everyone's interested in this thread's discussion.
It's a public message-board, unless for private matters one shouldn't resort to private messaging, imo.

Fwiw i have a response, but I typed it up earlier and it was really long and i got a 404. So i will repost tomorrow when I'm not on mobile.
 

SPDIF

Member
Ok, maybe this will be my last post in the thread.

Why would it be via PMs?
It's not off-topic and it's interesting to read for everyone's interested in this thread's discussion.
It's a public message-board, unless for private matters one shouldn't resort to private messaging, imo.

Well like I said I just don't think it's worth it to bump the thread every few hours to continue the discussion between just two people. But with that said, I didn't think anyone else was even interested in this discussion. Besides I think I've said everything I wanted to say. Unless CPP says something that I heavily disagree with, or provides me with that POC that I want :) then I don't think I'm going to reply (either through PM, or by posting here).
 
Of course, you're completely right about that. Just disregard what I said about the code signing, I was still thinking about exploits that execute from a downloaded file for some reason. So anyway, final point of contention:

Let's say that you've created a piece of malware that works by exploiting a BO somewhere in IE. A BO that you've somehow discovered and successfully tested without ever seeing the stack or any other debug info, since I doubt it's as easy to get as just attaching your favourite Windows debugger. Then the only question that remains is, how? Because as I've brought up on numerous occasions now, and I don't think you've addressed it yet, we're still running on the WinRT APIs. It's all well and good saying you'll smash out of the sandbox, but how can you when the only (kind of relevant) exploit example you've found is Win32 based?

I guess it just again comes back to the theoretical of "well I'm sure someone will eventually find a way". But I don't want theory, I want POCs :) If all you want to say is that, in theory, an Xbox could get a virus, then yes, I'm sure it can. In actual practice though, I really, really doubt that it will ever happen. Which is why throughout this thread I've been so adamant that the Xbox can't get viruses. It's not that in theory it can't, it's just in actuality it won't.

Anyway, this will be my last post in this thread. It seems pointless to randomly bump it every few hours just to reply to one another. You're more than welcome to reply to me, but any reply I make to you will be through a PM.

About WinRT. WinRT is just another sandbox. It's still built on top of the native Win32 API. All it takes is a WinRT sandbox escape and you have access to everything in Win32. Here's a presentation from blackhat that documents in some detail the technical design and security model of WinRT that someone who were attacking it would want to be familiar with. It's fairly technical, but you can skip to the conclusion if the technical details aren't your thing.

The other thing I wanted to mention is that in the Windows 8 universe, there are 3 types of applications. Desktop and Metro applications, which you are familiar with, and then... browsers. Yes, browsers are an entirely separate class of applications. Here is a document from Microsoft describing new experience browsers in more details. One thing that this document says is that a browser can choose which of the 3 types of app it is (it's literally in the first couple paragraphs, so you don't have to wade through much technical mumbo jumbo to get there). So it's certainly possible that a browser could be a pure Metro app. But, I know for a fact that IE on PC is of the 3rd category. This is important because it means IE is not a pure WinRT app, and this translates to more attack surface, and more potential attack vectors.

It is possible (but unlikely) that IE on Xbox One is a pure WinRT app. I say unlikely because they've put a ton of man hours into developing IE already, and it would be hard to imagine starting over from scratch just to achieve this kind of purity. And I wouldn't even be surprised if it were impossible due to technical limitations of features that IE supports. But, given that you can't actually run IE on Xbox One in desktop mode, I'm open to the possibility they've made it a pure Windows store app.

Anyway, the TL;DR of this post is: If IE on Xbox One is a WinRT app, there are still attack vectors. But I think it's not a pure WinRT app anyway and can access native APIs.

As for your final point, that it's probably technically possible but unlikely to occur in practice. I'm a little less convinced. I mean we are just speculating at this point, but I think there's a reasonable probability we'll see exploits on the Xbox One. There is a lot of institutional knowledge amongst attackers about Windows internals, as well as reverse engineering IE. Go look at some of the winning entries from the last few Pwn2owns. Very, very impressive stuff. And people already have a headstart since they know so much about Windows and IE anyway.
 

SPDIF

Member
Well since there's apparently some interest in this thread I guess I won't send a PM.

About WinRT. WinRT is just another sandbox. It's still built on top of the native Win32 API. All it takes is a WinRT sandbox escape and you have access to everything in Win32. Here's a presentation from blackhat that documents in some detail the technical design and security model of WinRT that someone who were attacking it would want to be familiar with.

I was waiting for you to link that. I've read it before (I'm not sure if you've read it all), and I have a few points I'll mention:


  • They take a very desktop oriented approach to the whole thing (which is understandable since they're talking about Metro apps on a PC), but it means certain exploits will completely fail on the XB1. The Xbox might be running Windows, but it's not full blown Windows, so any exploit that for example relies on launching Windows Media Player to connect to the internet wouldn't work (same goes for launching a malicious Excel document). Which brings me to the next point:
  • The XB1 is a very closed system compared to a PC. You can't exactly open up Olly Debug on the Xbox and get to work debugging a couple of DLLs, which obviously makes it far harder to find any weaknesses. And even if you take the approach of doing that on a PC and then assuming that'll work exactly the same on the Xbox, well, just re-read my first point. Speaking of DLLS:
  • "We would consider this type of exploit a vulnerability in the desktop applications rather than a vulnerability in the metro app or the platform" is what was said (admittedly by MS) in the paper about one of the attack methods that can potentially be successful (DLL Hijacking). Fortunately you don't have that pesky desktop on the Xbox.
  • Finally, the two main exploits that actually worked (ClickOnce and Broker memory corruption) are already fixed. But more importantly those exploits would involve the user actually installing an app in the first place, rather than an existing app being compromised. That's important because it means that in order for the app to even be downloadable in the first place it has to go to MS for analysis and testing, at which point any exploit would almost certainly be caught.

The other thing I wanted to mention is that in the Windows 8 universe, there are 3 types of applications. Desktop and Metro applications, which you are familiar with, and then... browsers. Yes, browsers are an entirely separate class of applications. Here is a document from Microsoft describing new experience browsers in more details. One thing that this document says is that a browser can choose which of the 3 types of app it is (it's literally in the first couple paragraphs, so you don't have to wade through much technical mumbo jumbo to get there). So it's certainly possible that a browser could be a pure Metro app. But, I know for a fact that IE on PC is of the 3rd category. This is important because it means IE is not a pure WinRT app, and this translates to more attack surface, and more potential attack vectors.

It is possible (but unlikely) that IE on Xbox One is a pure WinRT app. I say unlikely because they've put a ton of man hours into developing IE already, and it would be hard to imagine starting over from scratch just to achieve this kind of purity. And I wouldn't even be surprised if it were impossible due to technical limitations of features that IE supports. But, given that you can't actually run IE on Xbox One in desktop mode, I'm open to the possibility they've made it a pure Windows store app.

Heh, again, no need to tell me :) I've read that document as well as a few articles on MSDN when a few people and I attempted, and failed miserably, to create our own metro style desktop browser (not from scratch of course). But yeah, like you said, I was basing what I said on the idea that the browser would not be relying on any sort of desktop.

Anyway that's all I have to say. It's not that I'm really disagreeing with you, it's just more like I think it would be a hell of a lot harder to achieve than you seem to think it would be. So this really is my last post in this thread, because I know that if we go on like this we'll probably just start to repeat ourselves. You can have the last word if you like.

Thanks for the discussion :)
 
Top Bottom