Opera: we will reinvent the Web

[laca]

You don't need to own the machine with Opera's services. You just need to own the browser. That's the difference. There's no OS worries here, they have already set up the server inside their browser. If it's an attack vector coming from a downloaded content, say from an iframe or javascript hack, it still has to work on the OS level: Ie. it still has to root the box, which is different for linux and windows and mac. This is not a worry here. The services run *in the browser*

I just can't really imagine how you could bypass the OS entirely and make Opera's services do something they were not designed to do... I'm thinking about the security measures in place of course.

It has to be the same with Flash for example. What is stopping you from writing to the disk for example? Or connecting to some unauthorized location? Flash's security poilcies. In order to bypass those, you'd need to get to a lower level, possibly exploiting the actionscript engine itself (this has been done). And there you will have to deal with the OS.

If Opera is doing it right (which I assume they at least intend to), they also have security policies within Unite. And in order to bypass those...

 

[erlando]

I just can't really imagine how you could bypass the OS entirely and make Opera's services do something they were not designed to do... I'm thinking about the security measures in place of course.

It has to be the same with Flash for example. What is stopping you from writing to the disk for example? Or connecting to some unauthorized location? Flash's security poilcies. In order to bypass those, you'd need to get to a lower level, possibly exploiting the actionscript engine itself (this has been done). And there you will have to deal with the OS.

If Opera is doing it right (which I assume they at least intend to), they also have security policies within Unite. And in order to bypass those...

In Unite as in Java as in Flash you just need to exploit a buffer overflow.

For example: Apple JUST fixed this little bug in Java on OSX: http://www.net-security.org/secworld.php?id=7526 . No security policy can stop that.

The problem with Unite is that an open service is that much easier to attack. You don't need to coerce the user to download or visit a specially crafted site. You just need to send the right request to the service. Just like the countless SQLserver and IIS worms.

 

[Ducky]

In Unite as in Java as in Flash you just need to exploit a buffer overflow.

For example: Apple JUST fixed this little bug in Java on OSX: http://www.net-security.org/secworld.php?id=7526 . No security policy can stop that.

The problem with Unite is that an open service is that much easier to attack. You don't need to coerce the user to download or visit a specially crafted site. You just need to send the right request to the service. Just like the countless SQLserver and IIS worms.

erlando understands this. Unite is already running the service. You don't need to craft half of your botnet now, you just need to request the correct service and exploit it.

I have not tested this, but I sure am willing to. Mayhap I'll download this and get a few instances running and see what I can do with it.

 

[laca]

In Unite as in Java as in Flash you just need to exploit a buffer overflow.

For example: Apple JUST fixed this little bug in Java on OSX: http://www.net-security.org/secworld.php?id=7526 . No security policy can stop that.

The problem with Unite is that an open service is that much easier to attack. You don't need to coerce the user to download or visit a specially crafted site. You just need to send the right request to the service. Just like the countless SQLserver and IIS worms.

Yes, I said that it might be easier to exploit Unite. But still, exploiting a vulnerability (e.g. buffer overflow) is likely to depend on the OS.

 

[moopet]

I just thought I'd comment on the idea of freeing you from facebook etc. It's all well and good, but to have anywhere near the utility of a managed service, two things will have to happen:
You'll have to leave your desktop PC turned on 24/7
You'll install "web pages" downloaded from the Internet.

The first is a problem in terms of wasted power, greater exposure to attack and wearing out components faster. Ok, the last is weak, but groups of reasons always sound better in threes.

The second is stupid because they will be asking you to put their code into abritrary folders on your machine - and if you're using this, it's presumably because you don't know any better. This code will probably come from the sort of sites that give you free smilies - if it makes your opera page look like myspace, they will come.

 

[Wowbagger]

Actually, I do see wasted power as a deal-breaking issue. If everyone has to leave their machines on, at full power, all the time, it will only put more load onto the powerplants of the world.

What if a machine can be placed in a type of suspend mode where it can wake only when needed, to transfer stuff from its server files, using a minimum of power?
This technology already sort-of exists, but is not regularly used or available in most personal computers.

But, it doesn't look like Opera addresses that.

 

[GreNME]

Yes, I said that it might be easier to exploit Unite. But still, exploiting a vulnerability (e.g. buffer overflow) is likely to depend on the OS.

Nope, not if the service is like the JVM or other various plugins.

Yeah, it's already well-known that most plugin providers constantly patch their stuff to avoid overflows, but the problem is that Unite actually puts even more security onus on the users themselves, which has historically been the most easy-peasy way to root a machine out there. Overflowing code isn't always very easy, but tricking Aunt Rebecca to run some exploit code usually isn't.

If I weren't so busy with work stuff and keeping up with the Iran protests, I'd have devoted a night or two to re-dubbing that Unite video into one talking about how regular computers want the ability to spread viruses between people as First Class Carriers (or vectors), so that servers don't get the limelight for that functionality any more. Fake bank account login pages, cheap tricks to get you to send some stupid message or app to a friend or loved one (and thus infect them with a trojan), or simply sharing viruses from person to person, Unite makes this all possible, remaking the 21st century of Internet use. <cue closing music>

 

[laca]

Nope, not if the service is like the JVM or other various plugins.

The buffer overflow exists in the JVM itself, which is OS dependent code. To exploit it, you need to deal with that OS dependent code.

 

[Ducky]

The buffer overflow exists in the JVM itself, which is OS dependent code. To exploit it, you need to deal with that OS dependent code.

And with Opera running a service inside the browser, now we don't have that problem. ETA: If I run an (Pick: OpenSSH/Apache/Lighttpd/etc) server as a browser plug in, and it's offering services, it doesn't matter what OS it runs on to exploit a vulnerability in the core of that service. It's actively serving content and it's actively doing things that can be exploitable regardless of whether it's on a mac or windows. Content downloaded and run like a java applet or a flash video isn't at the same time actively reaching out to the rest of the world in the same way. A PHP/mysql website running on a windows server or a unix server is exploitable in similar enough ways to make the underlying OS an afterthought.

 

[jsiv]

I'm not really sure if I'm following this discussion.

Opera (and thus Unity) is native code, it's not running inside a Java VM or .NET which have real security barriers between them and the OS and which can theoretically be exploited in a platform-independent way without having to escape the sandbox.

If you're going to exploit a buffer overflow in Opera, you are going to be running platform-specific native code, and are going to be dealing with the memory layout of the platform in question and whatever countermeasures it has in place (on Windows, DEP and ASLR, and maybe ILs). There's nothing generic about this, and it's certainly not a given that the same bug can be exploited on all platforms.

Of course this doesn't actually matter all that much, since a single platform is still a heck of a lot of users (especially if it's Windows).

The only thing that potentially makes this more dangerous than a regular browser is that the action can be initiated by the exploiter rather than the user because it's a server. I think you're greatly exaggerating the actual risk.

 

[Ducky]

I'm not really sure if I'm following this discussion.

Opera (and thus Unity) is native code, it's not running inside a Java VM or .NET which have real security barriers between them and the OS and which can theoretically be exploited in a platform-independent way without having to escape the sandbox.

If you're going to exploit a buffer overflow in Opera, you are going to be running platform-specific native code, and are going to be dealing with the memory layout of the platform in question and whatever countermeasures it has in place (on Windows, DEP and ASLR, and maybe ILs). There's nothing generic about this, and it's certainly not a given that the same bug can be exploited on all platforms.

Of course this doesn't actually matter all that much, since a single platform is still a heck of a lot of users (especially if it's Windows).

The only thing that potentially makes this more dangerous than a regular browser is that the action can be initiated by the exploiter rather than the user because it's a server. I think you're greatly exaggerating the actual risk.

I'm not trying to exaggerate, I'm either not explaining myself well enough or missing something. This sums it up nicely, except to include that the issue of the exploiter being able to initiate this is a big problem. You don't have to own the whole box to do what it is you want to, simply execute a (theoretical at this point) vector of attack that throws an iframe into the served page that points to a known malware site and those that visit your photos now have a problem. THAT specific part (of visiting the newly changed service with the iframe attack) part is OS specific. The fact that you can serve this off any OS running the UNITE service is not OS specific.

 

[jsiv]

What, like a bug in the server that would let you rewrite the template it serves users? I suppose that could be platform-independent.

 

[Ducky]

What, like a bug in the server that would let you rewrite the template it serves users? I suppose that could be platform-independent.

and quickly scalable if this is product is to take off like Opera says.

 

[jsiv]

Hehe, what Opera says. Unite seems like a novelty thing that people will get bored with after a few minutes. This kind of functionality really belongs in an instant message client or something like that where you have an overview of who is online, not in a web browser.

 

[Ducky]

Hehe, what Opera says. Unite seems like a novelty thing that people will get bored with after a few minutes. This kind of functionality really belongs in an instant message client or something like that where you have an overview of who is online, not in a web browser.

I agree. My comment may have forgotten the sarcasm smilie.

 

[arthwollipot]

Opera Unite, reviewed on the Geeks Are Sexy blog.

 

[laca]

I'm not trying to exaggerate, I'm either not explaining myself well enough or missing something. This sums it up nicely, except to include that the issue of the exploiter being able to initiate this is a big problem.

Yes, I agree.

You don't have to own the whole box to do what it is you want to, simply execute a (theoretical at this point) vector of attack that throws an iframe into the served page that points to a known malware site and those that visit your photos now have a problem.

The real question is how exactly would you make it to serve a modified page? I simply cannot imagine a real-world scenario where this could be done without bumping into OS-specific stuff. I'd be really interested though in such an example.

THAT specific part (of visiting the newly changed service with the iframe attack) part is OS specific. The fact that you can serve this off any OS running the UNITE service is not OS specific.

Yes, but again, this depends on whether you can make Unite serve the modified page without bumping into the OS. And this is the part I have trouble believing.

 

[Ducky]

Yes, I agree.



The real question is how exactly would you make it to serve a modified page? I simply cannot imagine a real-world scenario where this could be done without bumping into OS-specific stuff. I'd be really interested though in such an example.



Yes, but again, this depends on whether you can make Unite serve the modified page without bumping into the OS. And this is the part I have trouble believing.

Read the link above, it confirms some preliminary testing of mine:

1) it subverts firewalls.
2) has filesystem access.

The above two are true regardless of OS platform with this.

The last piece of the puzzle is to find the attack vector to exploit the server. While I don't have that answer yet (not done testing) I suspect it won't be long until someone does find one.

It already has several functions out of the box that act much the same way malware creates a botnet addition (not surprising since they both are achieving the same goal: Server from your home machine.)

 

[laca]

Read the link above, it confirms some preliminary testing of mine:

1) it subverts firewalls.

Well, doh.

2) has filesystem access.

Yeah, it kind of has to have access... The question is to which part and what kind of access? Read-only? Read-write?

The above two are true regardless of OS platform with this.

The last piece of the puzzle is to find the attack vector to exploit the server. While I don't have that answer yet (not done testing) I suspect it won't be long until someone does find one.

It already has several functions out of the box that act much the same way malware creates a botnet addition (not surprising since they both are achieving the same goal: Server from your home machine.)

Yes, I have no doubt someone will find a way to exploit Unite. All I'm trying to say is that it won't be anything new.

 

[Ducky]

Well, doh.



Yeah, it kind of has to have access... The question is to which part and what kind of access? Read-only? Read-write?



Yes, I have no doubt someone will find a way to exploit Unite. All I'm trying to say is that it won't be anything new.

I'm not claiming it's new. I'm saying this has the makings of a bad idea, and could do this on whatever platform you install it on - ie. it's not just a windows malware problem.

Also: Passwords sent to this service are done so in plain text. I saw that in the link above, but hadn't found it yet. Tested and confirmed. While I understand why this is so (granting a CA for all those http ssl certs would be insane) it's still bad practice.



ETA:

The file system access is indeed read/write if the widget developer wants it so. See here:

http://www.betanews.com/article/How-secure-is-Opera-Unite/1245176152

Now, the Unite widget only exposes what this parameter permits the Opera proxy to expose through the virtual file system. However, according to the documentation, the level of access the end user has to that file system is determined by the corresponding level of access in the Unite server's physical file system. And according to a warning in the documentation, the job of securing that system is effectively left up to the developer.

"WARNING: Once mounted, the mount point will be read-write unless the underlying file system defines it to be read-only," the documentation reads. "Be careful to protect your data by controlling how data gets written to them. You should supply some sort of authentication of users who access these directories and be careful to not leave code open to exploitation."

I'm testing to see what I exploit. When I get answers I will post them here (and send to Opera.)