mirror/freebsd-ports
1
0
Fork 0
mirror of https://git.FreeBSD.org/ports.git synced 2024-12-13 03:03:15 +00:00
Code Issues Releases Activity

Add the latest two FreeBSD Security Advisories that have impact

Browse Source 
on -RELEASE versions. (RC's are not documented).

Hat:	secteam
This commit is contained in:
Remko Lodder 2013-09-19 05:44:02 +00:00
parent 13ee22748f
commit 2103e4aa48
Notes: svn2git 2021-03-31 03:12:20 +00:00 
svn path=/head/; revision=327595
1 changed files with 90 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
security/vuxml/vuln.xml
View File

@ -51,6 +51,94 @@ Note: Please add new entries to the beginning of this file.
-->
<vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
<vuln vid="b72bad1c-20ed-11e3-be06-000c29ee3065">
<topic>FreeBSD -- Cross-mount links between nullfs(5) mounts</topic>
<affects>
<system>
<name>FreeBSD</name>
<range><gt>9.1</gt><lt>9.1_7</lt></range>
<range><gt>8.4</gt><lt>8.4_4</lt></range>
<range><gt>8.3</gt><lt>8.3_11</lt></range>
</system>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>Problem Description:</p>
<p>The nullfs(5) implementation of the VOP_LINK(9) VFS
operation does not check whether the source and target of
the link are both in the same nullfs instance. It is
therefore possible to create a hardlink from a location in
one nullfs instance to a file in another, as long as the
underlying (source) filesystem is the same.</p>
<p>Impact:</p>
<p>If multiple nullfs views into the same filesystem are
mounted in different locations, a user with read access to
one of these views and write access to another will be able
to create a hard link from the latter to a file in the
former, even though they are, from the user's perspective,
different filesystems. The user may thereby gain write
access to files which are nominally on a read-only
filesystem.</p>
</body>
</description>
<references>
<cvename>CVE-2013-5710</cvename>
<freebsdsa>SA-13:13.nullfs</freebsdsa>
</references>
<dates>
<discovery>2013-09-10</discovery>
<entry>2013-09-19</entry>
</dates>
</vuln>
<vuln vid="4d87d357-202c-11e3-be06-000c29ee3065">
<topic>FreeBSD -- Insufficient credential checks in network ioctl(2)</topic>
<affects>
<system>
<name>FreeBSD</name>
<range><gt>9.1</gt><lt>9.1_7</lt></range>
<range><gt>8.4</gt><lt>8.4_4</lt></range>
<range><gt>8.3</gt><lt>8.3_11</lt></range>
</system>
</affects>
<description>
<body xmlns="http://www.w3.org/1999/xhtml">
<p>Problem Description:</p>
<p>As is commonly the case, the IPv6 and ATM network layer
ioctl request handlers are written in such a way that an
unrecognized request is passed on unmodified to the link
layer, which will either handle it or return an error
code.</p>
<p>Network interface drivers, however, assume that the
SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR and
SIOCSIFNETMASK requests have been handled at the network
layer, and therefore do not perform input validation or
verify the caller's credentials. Typical link-layer actions
for these requests may include marking the interface as "up"
and resetting the underlying hardware.</p>
<p>Impact:</p>
<p>An unprivileged user with the ability to run arbitrary code
can cause any network interface in the system to perform the
link layer actions associated with a SIOCSIFADDR,
SIOCSIFBRDADDR, SIOCSIFDSTADDR or SIOCSIFNETMASK ioctl
request; or trigger a kernel panic by passing a specially
crafted address structure which causes a network interface
driver to dereference an invalid pointer.</p>
<p>Although this has not been confirmed, the possibility that
an attacker may be able to execute arbitrary code in kernel
context can not be ruled out.</p>
</body>
</description>
<references>
<cvename>CVE-2013-5691</cvename>
<freebsdsa>SA-13:12.ifioctl</freebsdsa>
</references>
<dates>
<discovery>2013-09-10</discovery>
<entry>2013-09-19</entry>
</dates>
</vuln>
<vuln vid="7dfed67b-20aa-11e3-b8d8-0025905a4771">
<topic>mozilla -- multiple vulnerabilities</topic>
<affects>
@ -215,10 +303,12 @@ Note: Please add new entries to the beginning of this file.
</description>
<references>
<cvename>CVE-2013-4315</cvename>
<url>https://www.djangoproject.com/weblog/2013/sep/10/security-releases-issued/</url>
</references>
<dates>
<discovery>2013-09-10</discovery>
<entry>2013-09-12</entry>
<modified>2013-09-18</modified>
</dates>
</vuln>