24 ms·
From the PDF linked in the article: "Not the most interesting technically, but perhaps the most devastating (because of the ease of exploitation) bug is the br
by rolux 14y ago
From the PDF linked in the article:
"Not the most interesting technically, but perhaps the most devastating (because of the ease of exploitation) bug is the broken certificate validation in the Chase mobile banking app on Android. Even a primitive network attacker—for example, someone in control of a malicious Wi-Fi access point—can exploit this vulnerability to harvest the login credentials of Chase mobile banking customers."
- rolux 14y agoFurther down in the PDF, the authors present the decompiled source of the Chase app: public final void checkServerTrusted(X509Certificate[] paramArrayOfX509Certificate, String paramString) { if ((paramArrayOfX509Certificate != null) && ( paramArrayOfX509Certificate.length == 1)) paramArrayOfX509Certificate[0].checkValidity(); while (true) { return; this.a.checkServerTrusted( paramArrayOfX509Certificate, paramString); } } Good to know this isn't used for anything critical, just for, um, mobile banking.
- sukuriant 14y agoOkay. Please tell me I'm reading that wrong. void foo(X509Certificate[] a, String unused) { if( a != null && a.length == 1) a[0].checkValidity(); while(true){ return; /* never executed stuff */ foo(a, unused); } } X509Certificate.checkValidity()'s javadoc: http://docs.oracle.com/javase/1.5.0/docs/api/javax/security/cert/X509Certificate.html#checkValidity%28%29 http://docs.oracle.com/javase/1.5.0/docs/api/javax/security/... Selections from above link: Checks that the certificate is currently valid. It is if the current date and time are within the validity period given in the certificate. Throws: CertificateExpiredException - if the certificate has expired. CertificateNotYetValidException - if the certificate is not yet valid. There has got to be more to their code than this. It does nothing useful except make sure a random certificate is not expired. If there is no certificate, it doesn't fail or return false or anything. What is this!? Could this be a profiler-optimized set of code that really had a LOT more code to it? But then why would the bit of random junk after the return statement exist? Did no one do a proper code-review of this??? [edit: I used JavaSE 1.5 above; but I just checked Android's version and it looks to be the same, just less verbage in the docs.]
- rolux 14y agoThe issue with the code above is the return statement, most likely inserted during development, with the good intention to remove it later, since the "bit of random junk" that follows would have validated the server's certificate.
- sukuriant 14y agoBut it doesn't. It's calling the exact same function. As your sibling comment remarked, it looked like someone really frustrated with why they were getting a stack-overflow error and gave up.
- brown9-2 14y agoI'm not sure if things are different with the Android compiler, but javac will not compile code with an unreachable statement after a return like that.
- iclelland 14y agoThat almost hurts to look at -- It looks like a botched attempt at a recursive method to iterate through the array. I can imagine some poor developer, unable to figure out why it seems to always throw a StackOverflowException, putting that return statement in in frustration, and forgetting about it.
- gardarh 14y agoIt looks a lot like the output from an Android decompilation tool... which tends to return some weird stuff. That code segment would never compile (code immediately below a return/break/continue/etc. statement causes a compilation error).