Who's pretending? I do my surfing, then shut down the vm reverting to snapshot. If I've been infected it goes away.

As far as "regular users" I don't know the "they" do or not. I only know what I do.

My point is, the infection still takes place, so the VM is still breached. Sure, you can shut it down and it goes away (per say) but the infection still happened. Also, you can't expect normal people to work like you do, because they won't. And anyone that builds a system that works like that natively will have to deal with the complexities of having to automate the process. RIM's fault so far has been with the native slowness of VM designs.

Ragardless of that, in the future (dependant upon price of Flash), we're going to be seeing computers that have lockable Flash for their normal OS partitions so that issues like this won't happen. The Flash will be unlockable to applies updates, install apps, or make config changes, the the partition will relock after that happens. Think of them no diffent than ThinClients. Those TC systems now with lockable Flash are super nice. You can install them for a user and KNOW that the user can't do isht to break them, no matter what they hit. Power cycle them and the config is back to the way it was when you installed the box. When everyday PCs move to that type of design while still maintaining the speed and unlimited use of normal systems now, it'll be really nice.

My point is, the infection still takes place, so the VM is still breached. Sure, you can shut it down and it goes away (per say) but the infection still happened. Also, you can't expect normal people to work like you do, because they won't. And anyone that builds a system that works like that natively will have to deal with the complexities of having to automate the process. RIM's fault so far has been with the native slowness of VM designs.

Ragardless of that, in the future (dependant upon price of Flash), we're going to be seeing computers that have lockable Flash for their normal OS partitions so that issues like this won't happen. The Flash will be unlockable to applies updates, install apps, or make config changes, the the partition will relock after that happens. Think of them no diffent than ThinClients. Those TC systems now with lockable Flash are super nice. You can install them for a user and KNOW that the user can't do isht to break them, no matter what they hit. Power cycle them and the config is back to the way it was when you installed the box. When everyday PCs move to that type of design while still maintaining the speed and unlimited use of normal systems now, it'll be really nice.

Apple and Android also have some big security issues. As an aside an address space isn't really a VM using the classic defintion from IBM.

One will never get away from being a target and I know how to protect my self in cyber space. Doesn't mean a local merchant won't be unscrupulous with my credit info, there is only so much one can do.

Agreed... I never said otherwise. Read my other new thread on RSA being hacked. Nothing is secure... not even your own mind. There are drugs available to get every answer they need, even from you.

There are a lot of drugs available, unlike some other people, thankfully I don't need them.

Life is risky, to live is to face risk.

However, some things clearly carry more risk than others, vs the benefit of the risk.

Turning a blind eye to the risk doesn't make it less risky. Acknowledging that life is risky without gauging the risk is short-sided. In fact understanding the risk and then making informed decisions will lead to better choices.

There are a lot of drugs available, unlike some other people, thankfully I don't need them.

Life is risky, to live is to face risk.

However, some things clearly carry more risk than others, vs the benefit of the risk.

Turning a blind eye to the risk doesn't make it less risky. Acknowledging that life is risky without gauging the risk is short-sided. In fact understanding the risk and then making informed decisions will lead to better choices.

I think you misunderstood. The drugs I was speaking of are ones that can get info from even the security of your own mind (which I had expressed was the only place that's still secure in most cases).

1. Could you share how you know how the underpinnings of an undocumented operating system work?

Think about who you're asking that question to. RIM threatened to sue me when I revealed my very earliest BlackBerry reverse engineering work related to the engineering screen. Those threats doesn't mean my work stopped; I just chose to stop publicizing it to the world at large.

Originally Posted by i7guy

2. ASLR and DEP does not really prevent hacking on an intel platform, does it? (read: Windows and Mac OS, actually these days everthing is being hacked.)

The presence of ASLR and DEP considerably complicate exploitation of a flaw.

In a stack overflow vulnerability, you have activation-records/stack-frames for functions loaded on the stack, starting at the bottom (lower addresses) and going toward higher addresses. At the "front" of a frame (higher address), you have function book-keeping data structures that are managed by the compiler, including the memory address that should be returned to when the function completes execution. If you overflow a data field on the stack, you can overwrite these function structures in the stack and control the memory address of the execution.

Without DEP, an exploit can just stuff the shellcode payload into the stack at the same time as the overflow and have the return address jump to the shellcode in the stack. With DEP, the stack is marked as writable but not executable. If you manage to overflow the stack and even get the return address in the right place as the shellcode, it will fail to run, and the program will be terminated by the operating system.

To exploit a stack overflow on a system with active DEP, you need to modify the return address to execute real functions, which already exist in the program address space(i.e. system()), along with (data) arguments that you place on the stack. Since the overflowed return-address leads to a valid executable function, you bypass DEP. This is called a return-to-libc class attack and it's not as brain-dead simple to exploit as a simple stack smash.

What ASLR does is randomizes the loading memory offset of program code and program library code. This can defeat a simple version of a return-to-libc class attack, because the overflow code needs to know the exact address of a function to work. If they're randomly shifted by ASLR, the attacker needs to "guess" the address. If the address space is sufficiently large (like on 64-bit systems), it's too large to brute force this address with multiple attacks. With the wrong address, the program will try to execute jibberish and will also be terminated by the operating system.

If a system has both DEP and ASLR present, the level of technical competency required to exploit a vulnerability increases with it. The most advanced methods for bypassing both DEP and ASLR are things like JIT-spraying attacks against just-in-time compilers (this is how some recent Adobe Flash vulnerabilities work despite DEP/ASLR). JIT-spraying is a relatively new technique, and if you're interested, I suggest you read this good whitepaper about it: http://www.semantiscope.com/research...2010-Paper.pdf

So, no, they aren't foolproof, but the absence of them says a lot about the security engineering attitude at RIM.

Think about who you're asking that question to. RIM threatened to sue me when I revealed my very earliest BlackBerry reverse engineering work related to the engineering screen. Those threats doesn't mean my work stopped; I just chose to stop publicizing it to the world at large.

The presence of ASLR and DEP considerably complicate exploitation of a flaw.

In a stack overflow vulnerability, you have activation-records/stack-frames for functions loaded on the stack, starting at the bottom (lower addresses) and going toward higher addresses. At the "front" of a frame (higher address), you have function book-keeping data structures that are managed by the compiler, including the memory address that should be returned to when the function completes execution. If you overflow a data field on the stack, you can overwrite these function structures in the stack and control the memory address of the execution.

Without DEP, an exploit can just stuff the shellcode payload into the stack at the same time as the overflow and have the return address jump to the shellcode in the stack. With DEP, the stack is marked as writable but not executable. If you manage to overflow the stack and even get the return address in the right place as the shellcode, it will fail to run, and the program will be terminated by the operating system.

To exploit a stack overflow on a system with active DEP, you need to modify the return address to execute real functions, which already exist in the program address space(i.e. system()), along with (data) arguments that you place on the stack. Since the overflowed return-address leads to a valid executable function, you bypass DEP. This is called a return-to-libc class attack and it's not as brain-dead simple to exploit as a simple stack smash.

What ASLR does is randomizes the loading memory offset of program code and program library code. This can defeat a simple version of a return-to-libc class attack, because the overflow code needs to know the exact address of a function to work. If they're randomly shifted by ASLR, the attacker needs to "guess" the address. If the address space is sufficiently large (like on 64-bit systems), it's too large to brute force this address with multiple attacks. With the wrong address, the program will try to execute jibberish and will also be terminated by the operating system.

If a system has both DEP and ASLR present, the level of technical competency required to exploit a vulnerability increases with it. The most advanced methods for bypassing both DEP and ASLR are things like JIT-spraying attacks against just-in-time compilers (this is how some recent Adobe Flash vulnerabilities work despite DEP/ASLR). JIT-spraying is a relatively new technique, and if you're interested, I suggest you read this good whitepaper about it: http://www.semantiscope.com/research...2010-Paper.pdf

So, no, they aren't foolproof, but the absence of them says a lot about the security engineering attitude at RIM.

I actually didn't know who you were (more factually what you did) until a minute ago.

I understand this technical jargon, because I used to write operating systems. But that doesn't change the fact, that for a lot of reasons BlackBerries have not been common hacking targets, unlike Android and IOS who have been subject to multiple drive by and rooting vulnerabilities.

I read about JIT spraying, unless I have my references mixed up, some type of spraying technique was used to hack the Florida voting machines.

This is a good theoretical discussion, but in practice I don't worry about my desktop or my phone getting hacked.

You are more right than you believe. Too many people are dismissed because the masses do not know that there are more people on this board that actually know what they are talking about than just talking out of their arses.

But that doesn't change the fact, that for a lot of reasons BlackBerries have not been common hacking targets, unlike Android and IOS who have been subject to multiple drive by and rooting vulnerabilities.

I'm sure RIM and their customers love to believe that. Like it or not, a vulnerability in a high profile system is something that's publicized only when discovered by white-hat security researchers, and only when the vendor in question has a reasonable policy of dealing with responsible disclosure. If it's discovered by intelligence agencies or associated actors, they go into a bag of tricks to be leveraged at a later time.

WebKit isn't the only part of the BlackBerry operating system that resides in the soft-target native code. All media playback and decoding is also performed in native code, and this has been the case going back to the versions of OS 4.

Decoding/parsing media formats is a complex and error prone process, not unlike the complexity of parsing web pages.

I'm sure RIM and their customers love to believe that. Like it or not, a vulnerability in a high profile system is something that's publicized only when discovered by white-hat security researchers, and only when the vendor in question has a reasonable policy of dealing with responsible disclosure. If it's discovered by intelligence agencies or associated actors, they go into a bag of tricks to be leveraged at a later time.

WebKit isn't the only part of the BlackBerry operating system that resides in the soft-target native code. All media playback and decoding is also performed in native code, and this has been the case going back to the versions of OS 4.

Decoding/parsing media formats is a complex and error prone process, not unlike the complexity of parsing web pages.

Food for thought.

Liked I said on here before, if it has a browser, it can be hacked be it a computer or a Blackberry.

I'm sure RIM and their customers love to believe that. Like it or not, a vulnerability in a high profile system is something that's publicized only when discovered by white-hat security researchers, and only when the vendor in question has a reasonable policy of dealing with responsible disclosure. If it's discovered by intelligence agencies or associated actors, they go into a bag of tricks to be leveraged at a later time.

WebKit isn't the only part of the BlackBerry operating system that resides in the soft-target native code. All media playback and decoding is also performed in native code, and this has been the case going back to the versions of OS 4.

Decoding/parsing media formats is a complex and error prone process, not unlike the complexity of parsing web pages.

Who's pretending? I do my surfing, then shut down the vm reverting to snapshot. If I've been infected it goes away.

As far as "regular users" I don't know the "they" do or not. I only know what I do.

There are countermeasures built into hardware (Intel Processors) in addition to things like:

DEP - Explained earlier in the thread quite nicely; Introduced in Windows XP, maybe 2000 I don't wanna reinstall to look for it

UAC - Self-Explanatory; with Vista, but lots of users could have saved themselves grief by not running as an Admin and using "Run As..."/"Run As Administrator" for apps that needed the priviledges on XP/2000 (or any version of NT)

IE Protected Mode - Code downloaded through the browser and executed executes with the lowest priviledges and can only write to 'Temporary Internet Files' folder; Vista/IE7 (on by Default - doesn't work on XP even with IE8)

Sandboxing of Components like Adobe Flash and Adobe Reader - Self-Explanatory, but some modern Mobile OSes like WP7 implement it on a near-system wide bases

WebKit is pretty good but on a Windows Machine I would need to be proven wrong in my assessment that any WebKit Browser is more inherently secure than IE9 (not RTM'd).

And yes, Web Browsers are primary candidates for attack because they are given access to the internet and it increases the surface area of attack by hundreds of percentage points in some cases... It's very important to sandbox them, IMO, the way Microsoft did with IE in Vista/7...

Mobile phones are just really becoming primary candidates for attack because up until they became super popular the payout from exploiting PC users (who usually do not keep up with updates, and in many areas of the world users are using pirated software that they basically never update) using older easy-to-exploit software. Phones are becoming a primary target because in many cases people actually have more personal information on their phones than on their PCs. A PC is easier to secure than a smartphone for the average user, IMO, and has the resources to run the countermeasures and all other tasks flawlessly these days (as opposed to the Windows 98 days when an AV software could use up 20-30% of your RAM and slow your computer down to a halt due to slow hard drives).

Yes, but it wasn't originally designed for security and it's code is open source.
If RIM was running their old (substandard) browser, it would be a magnitude more difficult to hack; and the hackers already had to go through some hoops to get the hack working.

Of course RIM has no choice but to move forward with WebKit, but preferably sandbox it. Google Chrome is sandboxed up the wazoo and iirc it was not hacked at pwn2own.

Yes, but it wasn't originally designed for security and it's code is open source.
If RIM was running their old (substandard) browser, it would be a magnitude more difficult to hack; and the hackers already had to go through some hoops to get the hack working.

Of course RIM has no choice but to move forward with WebKit, but preferably sandbox it. Google Chrome is sandboxed up the wazoo and iirc it was not hacked at pwn2own.