[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201403222155.s2MLtYfM015229@linus.mitre.org>
Date: Sat, 22 Mar 2014 17:55:34 -0400 (EDT)
From: cve-assign@...re.org
To: dawgystyle@...hmail.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request - Uhuru Mobile Davfi Multiple Vulnerabilites
-----BEGIN PGP SIGNED MESSAGE-----
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.
>
> http://esec-lab.sogeti.com/post/A-quick-security-review-of-the-Uhuru-Mobile-demo-ROM
> https://www.davfi.fr/news/News_2014_03_21.pdf
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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTLgXLAAoJEKllVAevmvmsHiEIAL+kTM8qQNZR6H1GajXiZssG
dQVICfXwaFJ0CPxEGU/HHvUapjr7NPS14wfHpVMyKdYo+vUh0VXuPs7KuRORp6SS
iKg7Iq2XNPTQQ1yJ6YlBGI64EZ1I1i/UueFvUaBzxRyOkO9CYtCfG9imaXYmaLQj
wwr5Q0k8F3EpipH3jQl2Kj27y4hpN6iYLZJls/vzf3jzoBY5W2MFt5rCOZtIOIbB
yHaaZs9ZSpQGGZv/ynzkfTyI74qpU9cLM8NUtfVj+6g9J0Go7ZV6oYw/5xY+A+Pe
lgGdwBYYzTJesPlKCh+LAXpZrCJr4VdFEK8Hpopk71MERXhE/m8bSZrxeNL3GyI=
=loZz
-----END PGP SIGNATURE-----
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.
