Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 22 Mar 2014 17:55:34 -0400 (EDT)
Subject: Re: CVE Request - Uhuru Mobile Davfi Multiple Vulnerabilites

Hash: SHA1

> Multiple vulnerabilities were found in the Uhuru Mobile ROM. These
> vulnerabilities were detailed in a blogpost
> Eric Filiol, the main creator of the project, responded (in french) to
> the reported vulnerabilities.

This is a somewhat unusual case in which the vendor response is
available only in French (the CVE project primarily uses English), and
apparently the only available format of the response is PDF with
"Document Restrictions ... Content Copying: Not Allowed." Possibly
the easiest way to do automated translation would be OCR.

The primary issue is that the nature of the product availability is
outside the scope of CVE. The vendor response states that the
availability was a first demonstration and that the target audience
was the security community. When providing CVE assignments, what we're
looking for is software that is, roughly speaking, intended to be used
and not simply tested. This varies from product to product. For some
open-source projects, this means that the vendor must make a release
intended for typical end users. For other open-source projects, it is
known that unreleased software (e.g., from a git master branch) is
directly incorporated into commercial products from time to time, and
thus the lack of a release by the project maintainers isn't critical.
This second case doesn't seem to apply to the Uhuru Mobile product.

In the first case, if a vendor hires a specific security consultant to
do a vulnerability assessment of an unreleased product, neither the
consultant nor the vendor is eligible to obtain CVE assignments for
this work. (People do occasionally try.) Similarly, if there isn't a
specific security consultant, and the vendor instead is trying to
engage any interested person in the security community, CVE
assignments aren't made.

We also have other comments about the disclosure:

> Vulnerability #2 - Embedded kernel vulnerable to CVE-2013-6282 (local
> root)

> Vulnerability #3 - Embedded kernel vulnerable to CVE-2013-4787
> (master key)

Even if this were a released product, there wouldn't be separate CVE
assignments for instances of CVE-2013-6282 and CVE-2013-4787. Those
IDs would be used directly.

> Vulnerability #1 - Whitelist of executable applications bypass:
> ----------------------------
> The Android kernel was modified and "hardened". A feature was
> implemented to only allow a whitelist of binaries to be executed. This
> can be bypassed by using, for example, the LD_PRELOAD environment
> variable.

Based on section 2.2, our understanding is that the vendor believes
this is resultant from "shell obtenu auparavant." (Admittedly, the
vendor apparently plans to address this anyway as an additional
security-hardening measure. See the end of the "2. Pour les
librairies" section.)

> bruteforce it if it is encrypted

In section 2.6, the vendor apparently believes that 16-character
alphanumeric PIN values are a mitigation.

Finally, in section 2.1, the vendor apparently asserts that the attack
is possible only when following a process that is contrary to the
installation instructions.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.