NetBSD Bloghttps://blog.netbsd.org/tnf/feed/entries/atom2024-03-17T12:20:22+00:00Apache Roller (incubating)https://blog.netbsd.org/tnf/entry/network_security_auditNetwork Security AuditMaxime Villard2018-05-28T07:01:14+00:002018-05-28T07:03:10+00:00<i>Security audit of NetBSD's network stack</i>
<p>As a part of a funded project, I am conducting a security audit of NetBSD’s
network stack. The work will end soon, and I would like to briefly present
some results.
<p>
<h2>Fixing, Strengthening, Simplifying</h2>
<p>
Over the last five months, hundreds of patches were committed to the source tree
as a result of this work. Dozens of bugs were fixed, among which a good number
of actual, remotely-triggerable vulnerabilities.
<p>
Changes were made to strengthen the networking subsystems and improve code
quality: reinforce the mbuf API, add many KASSERTs to enforce assumptions,
simplify packet handling, and verify compliance with RFCs. This was done in
several layers of the NetBSD kernel, from device drivers to L4 handlers.
<p>
A lot of cleanup took place, too. For example I managed to remove more than
one thousand lines of code in IPsec, while at the same time improving
robustness and performance. This kind of cleanup results in a networking code
that is much easier to understand and maintain.
<p>
The fixes for critical bugs were quickly propagated to the stable branches
(NetBSD-6, NetBSD-7) and the NetBSD-8_BETA branch. Along the way, several
changes too were discreetly propagated, when they were considered as good
mitigations against possible attack vectors.
<p>
<h2>Fixes in Other Operating Systems</h2>
<p>
In the course of investigating several bugs discovered in NetBSD, I happened
to look at the network stacks of other operating systems, to see whether they
had already fixed the issues, and if so how. Needless to say, I found bugs
there too.
<p>
So far the trophies are:
<center>
<table>
<tr>
<th>NetBSD</th>
<th>OpenBSD</th>
<th>FreeBSD</th>
</tr>
<tr>
<td>SA2018-003 (1)</td>
<td>6.2-Errata-#005 (2)</td>
<td>SA-18:01.ipsec (2)</td>
</tr>
<tr>
<td>SA2018-004 (1)</td>
<td>6.2-Errata-#006 (1)</td>
<td>SA-18:05.ipsec (2)</td>
</tr>
<tr>
<td>SA2018-006 (5+)</td>
<td>6.2-Errata-#007 (1)</td>
<td></td>
</tr>
<tr>
<td>SA2018-007 (10)</td>
<td>6.2-Errata-#010 (1)</td>
<td></td>
</tr>
<tr>
<td>SA2018-008 (2)</td>
<td>6.3-Errata-#006 (2)</td>
<td></td>
</tr>
<tr>
<td></td>
<td>6.3-Errata-#008 (1)</td>
<td></td>
</tr>
</table>
<br>
<font size="1">Fig. A: advisory_name (number_of_bugs).</font>
</center>
<p>
Of course, I am focusing on NetBSD, so it is no surprise the number of bugs
found there is higher than in the other OSes.
<p>
Also, it is to be noted that FreeBSD hasn’t yet published advisories for
several bugs that I reported to them (which they nonetheless fixed pretty
quickly).
<p>
<h2>Some Examples</h2>
<h3>The IPv6 Buffer Overflow</h3>
<p>
In January I discovered, in NetBSD’s IPv6 stack, a subtle buffer overflow,
which turned out to affect the other BSDs as well.
<p>
The overflow allowed an attacker to write one byte of packet-controlled data
into ‘packet_storage+off’, where ‘off’ could be approximately controlled too.
<p>
This allowed at least a pretty bad remote DoS: by sending specially-crafted
packets in a loop, an attacker could overwrite several areas of memory with
wrong values, which would eventually lead to undefined behavior and crash.
<p>
One way of exploiting this bug was to use a special combination of nested
fragments.
<p>
<center>
<img src="//www.netbsd.org/~maxv/netaudit/FigB.png">
<br>
<font size="1">Fig. B: A simplified view.</font>
</center>
<p>
In short, when receiving the last fragment of a packet, the kernel would
iterate over the previous IPv6 options of the packet, assuming that everything
was located in the first mbuf. It was possible to break this assumption, by
sending a fragment nested into another.
<p>
Given the nature of the bug there were probably other (and perhaps more
direct) ways to trigger it.
<p>
This overflow was of course fixed pretty quickly, but in addition the NetBSD
kernel was changed to automatically drop nested fragments. This is an example
of the many miscellaneous changes made in order to strengthen the network
stack.
<p>
<h3>The IPsec Infinite Loop</h3>
<p>
When receiving an IPv6-AH packet, the IPsec entry point was not correctly
computing the length of the IPv6 suboptions, and this, <b>before</b>
authentication. As a result, a specially-crafted IPv6 packet could trigger an
infinite loop in the kernel (making it unresponsive). In addition this flaw
allowed a limited buffer overflow - where the data being written was however
not controllable by the attacker.
<p>
The other BSDs too were affected by this vulnerability. In addition they were
subject to another buffer overflow, in IPv4-AH this time, which happened to
have been already fixed in NetBSD several years earlier.
<p>
<h3>The IPPROTO Typo</h3>
<p>
While looking at the IPv6 Multicast code, I stumbled across a pretty simple
yet pretty bad mistake: at one point the Pim6 entry point would return
IPPROTO_<b>N</b>ONE instead of IPPROTO_<b>D</b>ONE. Returning IPPROTO_NONE was entirely
wrong: it caused the kernel to keep iterating on the IPv6 packet chain, while
the packet storage was already freed.
<p>
Therefore it was possible to remotely cause a use-after-free if the packet
was forged in such a way that the kernel would take the IPPROTO_NONE branch.
Generally the kernel would panic shortly afterwards, because it figured out it
was double-freeing the same packet storage. (A use-after-free detector is also
one of the things that were added in NetBSD to prevent the exploitation of
such bugs.)
<p>
This typo was found in the Multicast entry code, which is enabled only with a
particular, non-default configuration. Therefore it didn’t affect a default
install of NetBSD.
<p>
While looking for other occurrences of this typo, I found the exact same bug
in the exact same place in FreeBSD. Curiously enough, OpenBSD had the same bug
too, but in a totally different place: the typo existed in their EtherIP entry
point, but there, it was more dangerous, because it was in a branch taken by
default, and therefore a default install of OpenBSD was vulnerable.
<p>
<h3>The PF Signedness Bug</h3>
<p>
A bug was found in NetBSD’s implementation of the PF firewall, that did not
affect the other BSDs. In the initial PF code a particular macro was used as
an alias to a number. This macro formed a signed integer.
<p>
In NetBSD, however, the macro was defined differently: it contained the
<i>sizeof</i> statement. This was a terrible mistake, because it resulted in
an <b>unsigned</b> integer.
<p>
This was not the intended signedness. Given that the macro in question was used
to perform length validation checks in PF’s TCP-SYN entry point when a modulate
rule was active, it was easy to cause a remote DoS by sending a malformed
packet.
<p>
But PF was not a component I was supposed to look at as part of my work. So how
did I still manage to find this bug? Well, while closing dozens of reports in
NetBSD’s Problem Report database, I stumbled across a PR from 2010, which was
briefly saying that PF’s TCP-SYN entry point could crash the kernel if a
special packet was received. Looking at the PF code, it was clear, after two
minutes, where the problem was.
<p>
<h3>The NPF Integer Overflow</h3>
<p>
An integer overflow could be triggered in NPF, when parsing an IPv6 packet with
large options. This could cause NPF to look for the L4 payload at the wrong
offset within the packet, and it allowed an attacker to bypass any L4 filtering
rule on IPv6.
<p>
<center>
<img src="//www.netbsd.org/~maxv/netaudit/FigC.png">
<br>
<font size="1">Fig. C: Simplified example of an exploit.</font>
</center>
<p>
In the example above, NPF allows the packet to enter, based on validation
performed on the wrong TCP header (orange, dashed lines). The kernel reads the
correct TCP header (red), and delivers it to a socket. NPF was supposed to
reject it.
<p>
More generally, several problems existed in NPF’s handling of IPv6 packets.
<p>
<h3>The IPsec Fragment Attack</h3>
<font size="1">(A more detailed example)</font>
<p>
I noticed some time ago that when reassembling fragments (in either IPv4 or
IPv6), the kernel was not removing the M_PKTHDR flag on the secondary mbufs in
mbuf chains. This flag is supposed to indicate that a given mbuf is the head of
the chain it forms; having the flag on secondary mbufs was suspicious.
<p>
Later, deep in the IPsec-ESP handler, I found a function that was assuming that
M_PKTHDR was set only in the first mbuf of the chain – assumption that
evidently didn’t hold, since reassembled fragments had several M_PKTHDRs. Later
in the handler, it resulted in a wrong length being stored in the mbuf header
(the packet had become shorter than the actual length registered). The wrong
length would in turn trigger a kernel panic shortly afterwards.
<p>
This remote DoS was triggerable if the ESP payload was located in a secondary
mbuf of the chain, which never is the case in practice. The function in
question was called after ESP decryption. Therefore, in order for an attacker
to reach this place, it was necessary to send a correct ESP payload – which
meant having the ESP key. So at a first glance, this looked like a non-critical
bug.
<p>
But there was still a theoretical way to exploit the bug. In the case of IPv6 at least, the
IP options can be huge, and more importantly, can be located in the <b>unencrypted</b>
part of the packet. Let’s say you are MITMing a NetBSD host that is having an
ESP conversation with another host. You intercept a packet directed to the
NetBSD host. You take the ESP payload as-is (which you can’t decrypt since you
don’t have the key), you craft a new two-fragment packet: you put the other
IPsec host’s IPv6 address as source, insert a dummy IP option in the first
fragment, insert the ESP payload as-is in the second fragment, and send the two
fragments to the NetBSD host.
<p>
The NetBSD host reassembles the fragments, decrypts the ESP payload correctly,
reaches the aforementioned handler, miscomputes the packet length, and crashes.
<p>
The other BSDs were affected.
<p>
<h3>And the rest...</h3>
<p>
Many security fixes and improvements in different places that I didn’t list
here.
<p>
<h2>What Now</h2>
Not all protocols and layers of the network stack were verified, because of
time constraints, and also because of unexpected events: the recent x86 CPU
bugs, which I was the only one able to fix promptly. A todo list will be left
when the project end date is reached, for someone else to pick up. Me perhaps,
later this year? We’ll see.
<p><p>
<i>
This security audit of NetBSD’s network stack is sponsored by The NetBSD
Foundation, and serves all users of BSD-derived operating systems. The NetBSD
Foundation is a non-profit organization, and welcomes any donations that help
continue funding projects of this kind.
</i>
<p><p>https://blog.netbsd.org/tnf/entry/recent_security_affairsRecent Security AffairsMaxime Villard2018-02-05T07:43:06+00:002018-02-05T07:43:06+00:00An update on the recent security affairs and how they are, or were, handled on NetBSD<i>
An update on the recent security affairs and how they are, or were, handled on
NetBSD
</i>
<p>
<h1>DEFCON 25 and 34c3</h1>
<p>
Ilja Van Sprundel presented at Defcon 25 (July 2017) and 34c3 (December 2017)
the results of his audit of the BSD kernels.
<p>
The issues affecting NetBSD were fixed overnight in the NetBSD-current branch,
and were propagated to the stable branches within a month. Kernels from NetBSD-6
and NetBSD-7 built after August 23rd 2017 had all the necessary fixes.
<p>
Some reports published recently suggest that the stable branches remained
vulnerable for months, and that NetBSD was lagging behind; that is simply not
true.
<p>
In Ilja Van Sprundel’s report, NetBSD was criticized for having too much legacy
and buggy code. Several proactive measures were taken, within a month again, to
clean up the system. These measures were:
<p>
<ul>
<li>TCP_COMPAT_42 was removed.</li>
<li>COMPAT_FREEBSD was disabled.</li>
<li>COMPAT_SVR4 and COMPAT_SVR4_32 were disabled on all architectures.</li>
<li>COMPAT_IBCS2 was disabled on all architectures but Vax.</li>
<li>COMPAT_SVR4 support for i386 was removed.</li>
<li>COMPAT_IBCS2 support for i386 was removed.</li>
<li>VM86 was removed.</li>
</ul>
<p>
Several of these changes were propagated to the stable branches. Since, several
additional improvements were made to further externalize some parts of the kernel,
in such a way that features can be taken out of the system by default, but still
be loaded as kernel modules dynamically when they are needed. This aims, of
course, at reducing the attack surface in the base system.
<p>
Due to the limited human resources available in security-team@, Security
Advisories generally take time to be issued. A Security Advisory for the
reported problems had not been issued in time, and it was decided <b>not to
issue one</b>. The Security Team will continue working on more recent security
issues.
<p>
<h1>Meltdown and Spectre</h1>
<p>
The counter-measure for Meltdown, called SVS (<i>Separate Virtual Space</i>), is
being developed. It was first committed on January 7th 2018, and has now reached
a stable state. It is available only on x86 64bit (amd64) for now, this
architecture being our primary target.
<p>
A significant effort is required to back-port SVS to the stable branches: many
improvements were made in the amd64 port (better security and performance) since
the last release, and they will have to be, at some point, back-ported too.
<p>
Regarding Spectre, Intel and AMD have issued microcode updates. In the case of
Intel, the new microcode adds several MSRs, that the OS can tune to disable
branch prediction. Given that NetBSD supports microcode updates, it is possible
to install a new microcode; however, no option is available yet to tune the
aforementioned MSRs.
<p>
It is not clear whether the fixes proposed by Intel and AMD are sufficiently
reliable. Recent reports suggest that some CPUs have started misbehaving when
running with the new microcodes. Therefore, the fix for Spectre is expected to
take a little more time to produce than that of Meltdown.
<p>https://blog.netbsd.org/tnf/entry/the_strongest_kaslr_everThe strongest KASLR, ever?Maxime Villard2017-11-20T12:50:15+00:002017-11-20T12:50:15+00:00<i>latest developments in the Kernel ASLR district</i><i>latest developments in the Kernel ASLR district</i>
<p>
<h1>Initial design</h1>
<p>
As I said in the
<a href="https://blog.netbsd.org/tnf/entry/kernel_aslr_on_amd64">previous episode</a>,
I added in October a Kernel ASLR implementation in NetBSD for 64bit x86 CPUs.
This implementation would randomize the location of the kernel in virtual memory
as one block: a random VA would be chosen, and the kernel ELF sections would be
mapped contiguously starting from there.
<p>
This design had several drawbacks: one leak, or one successful cache attack,
could be enough to reconstruct the layout of the entire kernel and defeat KASLR.
<p>
NetBSD’s new KASLR design significantly improves this situation.
<p>
<h1>New design</h1>
<p>
In the new design, each kernel ELF section is randomized independently. That is
to say, the base addresses of .text, .rodata, .data and .bss are not correlated.
KASLR is already at this stage more difficult to defeat, since you would need
a leak or cache attack on each of the kernel sections in order to reconstruct
the in-memory kernel layout.
<p>
Then, starting from there, several techniques are used to strengthen the
implementation even more.
<p>
<h2>Sub-blocks</h2>
<p>
The kernel ELF sections are themselves split in sub-blocks of approximately 1MB.
The kernel therefore goes from having:
<pre>
{ .text .rodata .data .bss }
</pre>
to having
<pre>
{ .text .text.0 .text.1 ... .text.i .rodata .rodata.0 ... .rodata.j ... .data ...etc }
</pre>
As of today, this produces a kernel with ~33 sections, <b>each of which</b> is
mapped at a random address and in a random order.
<p>
This implies that there can be dozens of .text segments. Therefore, even if
you are able to conduct a cache attack and determine that a given range of
memory is mapped as executable, you don’t know which sub-block of .text it is.
If you manage to obtain a kernel pointer via a leak, you can at most guess the
address of the section it finds itself in, but you don’t know the layout of the
remaining 32 sections. In other words, defeating this KASLR implementation is
much more complicated than in the initial design.
<p>
<h2>Higher entropy</h2>
<p>
Each section is put in a 2MB-sized physical memory chunk. Given that the
sections are 1MB in size, this leaves half of the 2MB chunk unused. Once in
control, the prekern shifts the section within the chunk using a random offset,
aligned to the ELF alignment constraint. This offset has a maximum value of 1MB,
so that once shifted the section still resides in its initial 2MB chunk:
<p>
<center>
<img src="//www.netbsd.org/~maxv/kaslr/FigA.png">
<br>
<font size="1">Fig. A: Physical memory, a random offset has been added.</font>
</center>
<p>
The prekern then maps these 2MB physical chunks at random virtual addresses; but
addresses aligned to 2MB. For example, the two sections in Fig. A will be mapped
at two distinct VAs:
<p>
<center>
<img src="//www.netbsd.org/~maxv/kaslr/FigB.png">
<br>
<font size="1">Fig. B: two random, 2MB-aligned ranges of VAs point to the chunks
the sections find themselves in.</font>
</center>
<p>
There is a reason the sections are shifted in memory: it offers higher entropy.
If we consider a .text.i section with a 64byte ELF alignment constraint, and
give a look at the number of possibilities for the location of the section in
memory:
<p>
<ul>
<li>The prekern shifts the 1MB section in its 2MB chunk, with an offset aligned
to 64 bytes. So there are (2MB-1MB)/(64B)=2<sup>14</sup> possibilities for the
offset.</li>
<li>Then, the prekern uses a 2MB-sized 2MB-aligned range of VA, chosen in a 2GB
window. So there are (2GB-2MB)/(2MB)=2<sup>10</sup>-1 possibilities for the VA.</li>
</ul>
<p>
Therefore, there are 2<sup>14</sup>x(2<sup>10</sup>-1)≈2<sup>24</sup>
possible locations for the section. As a comparison with other systems:
<p>
<center>
<table>
<tr>
<th>OS</th>
<th># of possibilities</th>
</tr>
<tr>
<td>Linux</td>
<td><center>2<sup>6</sup></center></td>
</tr>
<tr>
<td>MacOS</td>
<td><center>2<sup>8</sup></center></td>
</tr>
<tr>
<td>Windows</td>
<td><center>2<sup>13</sup></center></td>
</tr>
<tr>
<td>NetBSD</td>
<td><center>2<sup>24</sup></center></td>
</tr>
</table>
<br>
<font size="1">Fig. C: comparison of entropies. Note that the other KASLR
implementations do not split the kernel sections in sub-blocks.</font>
</center>
<p>
Of course, we are talking about one .text.i section here; the sections that
will be mapped afterwards will have fewer location possibilities because some
slots will be already occupied. However, this does not alter the fact that the
resulting entropy is still higher than that of the other implementations.
Note also that several sections have an alignment constraint smaller than 64
bytes, and that in such cases the entropy is even higher.
<p>
<h2>Large pages</h2>
<p>
There is also a reason we chose to use 2MB-aligned 2MB-sized ranges of VAs:
when the kernel is in control and initializes itself, it can now use large pages
to map the physical 2MB chunks. This greatly improves memory access
performance at the CPU level.
<p>
<h2>Countermeasures against TLB cache attacks</h2>
<p>
With the memory shift explained above, randomness is therefore enforced at both
the physical and virtual levels: the address of the first page of a section
does not equal the address of the section itself anymore.
<p>
It has, as a side effect, an interesting property: it can mostly mitigate
TLB cache attacks. Such attacks operate at the virtual-page level; they will
allow you to know that a given large page is mapped as executable, but you don’t
know where exactly within that page the section actually begins.
<p>
<h1>Strong?</h1>
<p>
This KASLR implementation, which splits the kernel in dozens of sub-blocks,
randomizes them independently, while at the same time allowing for higher
entropy in a way that offers large page support and some countermeasures
against TLB cache attacks, appears to be the most advanced KASLR implementation
available publicly as of today.
<p>
Feel free to prove me wrong, I would be happy to know!
<p>
<h1>WIP</h1>
<p>
Even if it is in a functional state, this implementation is still a work in
progress, and some of the issues mentioned in the
<a href="https://blog.netbsd.org/tnf/entry/kernel_aslr_on_amd64">previous blog post</a>
haven't been addressed yet. But feel free to test it and report any issue you
encounter. Instructions on how to use this implementation can still be found in
the previous blog post, and haven’t changed since.
<p>
See you in the next episode!
<p>
https://blog.netbsd.org/tnf/entry/kernel_aslr_on_amd64Kernel ASLR on amd64Maxime Villard2017-10-12T05:11:55+00:002017-10-12T05:11:55+00:00Recently, I completed a Kernel ASLR implementation for NetBSD-amd64, making
NetBSD the first BSD system to support such a feature. Simply said, KASLR is a
feature that randomizes the location of the kernel in memory, making it harder
to exploit several classes of vulnerabilities, both locally (privilege
escalations) and remotely (remote code executions).Recently, I completed a Kernel ASLR implementation for NetBSD-amd64, making
NetBSD the first BSD system to support such a feature. Simply said, KASLR is a
feature that randomizes the location of the kernel in memory, making it harder
to exploit several classes of vulnerabilities, both locally (privilege
escalations) and remotely (remote code executions).
<p>
<h1>Current design</h1>
<p>
The current design is based on a specialized kernel called the "prekern", which
operates between the bootloader and the kernel itself. The kernel is compiled
as a raw library with the GENERIC_KASLR configuration file, while the prekern
is compiled as a static binary. When the machine boots, the bootloader jumps
into the prekern. The prekern relocates the kernel at a random virtual address
(VA), and jumps into it. Finally, the kernel performs some cleanup, and executes
normally.
<p>
Currently, the kernel is randomized as a single block. That is to say, a random
VA is chosen, and the kernel text->rodata->data sections are mapped
contiguously starting from there. It has several drawbacks, but it's a first
shot.
<p>
To complete this implementation, work had to be done at three levels: the
bootloader, the prekern and the kernel. I committed several of the kernel and
bootloader patches discreetly a few months ago, to pave some way for real
changes. In the past few weeks, I changed the low-level x86 layer of the kernel
and replaced several hard-coded (and sometimes magic) values by variables, in
such a way that the kernel can run with a non-static memory layout. Finally, the
last step was committing the prekern itself to the source tree.
<p>
<h1>Future work</h1>
<p>
<ul>
<li>Randomize the kernel sections independently, and intertwine them.</li>
<li>Modify several kernel entry points not to leak kernel addresses to userland.</li>
<li>Randomize the kernel heap too (which is still static for now).</li>
<li>Fix a few other things that need some more work.</li>
</ul>
<p>
<h1>How to use</h1>
<p>
All of the patches are now in NetBSD-current. Instructions on how to
install and use this implementation can be found
<a href="https://m00nbsd.net/542a5cfd448aaf7db7adcadce74123d2.html">here</a>;
they are inlined below, and probably won't change in the future.
<p>
Make sure you have a v5.11 bootloader installed. If you don't, build and install
a new bootloader:
<pre>
$ cd /usr/src/sys/arch/i386/stand/boot
$ make
# cp biosboot/boot /
</pre>
Build and install a KASLR kernel:
<pre>
$ cd /usr/src
$ ./build.sh -u kernel=GENERIC_KASLR
# cp /usr/obj/sys/arch/amd64/compile/GENERIC_KASLR/netbsd /netbsd_kaslr
</pre>
Finally, build and install a prekern:
<pre>
$ cd /usr/src/sys/arch/amd64/stand/prekern
$ make
# cp prekern /prekern
</pre>
Reboot your machine. In the boot prompt, enter:
<pre>
> pkboot netbsd_kaslr
</pre>
The system will boot with no further user interaction. Should you encounter
any regression or unexpected behavior, please report it immediately
to tech-kern.
<p>
Note that you can still boot a static kernel, by typing as usual:
<pre>
> boot netbsd
</pre>
<h1>Availability</h1>
<p>
This KASLR implementation will be available starting from NetBSD 9. Once it is
stabilized, it may be backported to NetBSD 8. Until then, feel free to test it!
<p><p>https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa2011New Security Advisories: NetBSD-SA2011-002 OpenSSL TLS race condition and NetBSD-SA2011-003 kernel memory exhaustionTonnerre Lombard2011-03-08T12:26:58+00:002011-03-09T09:04:00+00:00Two new NetBSD Security Advisories have been published affecting OpenSSL and the kernel.
<p><p> Two new security advisories were published:</p>
<ul type="disc"><li>
<a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2011-002.txt.asc" target="_top">NetBSD-SA2011-002</a> OpenSSL TLS extension parsing race condition.</li>
<li>
<a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2011-003.txt.asc" target="_top">NetBSD-SA2011-003</a> Exhausting kernel memory from user controlled value</li></ul>
<p>
You can find more information about them on the <a href="http://www.netbsd.org/support/security/" target="_top">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa20101New Security Advisories: NetBSD-SA2010-012 OpenSSL TLS race condition and NetBSD-SA2010-013 UDP6 Option Local DoSTonnerre Lombard2010-11-29T16:01:30+00:002010-11-29T16:01:30+00:00<p> Two new security advisories were published:</p>
<ul type="disc">
<li><a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-012.txt.asc" target="_top">NetBSD-SA2010-012</a> OpenSSL TLS extension parsing race condition.</li>
<li><a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-013.txt.asc" target="_top">NetBSD-SA2010-013</a> UDP6 Option Parsing local Denial of Service</li>
</ul>
<p>
You can find more information about them on the <a href="http://www.netbsd.org/support/security/">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisory_netbsd_sa20102New Security Advisory: NetBSD-SA2010-008 sftp(1)/ftp(1)/glob(3) related resource exhaustionTonnerre Lombard2010-10-07T07:27:23+00:002011-03-08T12:26:02+00:00A new NetBSD security advisory has been published affecting the glob library and the SSH (sftp) and FTP daemons.
<p><p> One new security advisory was published:</p>
<ul type="disc"><li>
<a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc" target="_top">NetBSD-SA2010-008</a> sftp(1)/ftp(1)/glob(3) related resource exhaustion</li></ul>
<p>
You can find more information about it on the <a href="http://www.netbsd.org/support/security/" target="_top">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisory_netbsd_sa20101New Security Advisory: NetBSD-SA2010-007 Integer overflow in libbz2 decompression codeTonnerre Lombard2010-09-29T00:13:58+00:002010-09-29T00:13:59+00:00<p>A new NetBSD security advisory has been published affecting the bzip2(1) program, the libbz2 library and the rescue system.</p><p> One new security advisory was published:</p>
<ul type="disc">
<li><a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-007.txt.asc" target="_top">NetBSD-SA2010-007</a> Integer overflow in libbz2 decompression code</li>
</ul>
<p>
You can find more information about them on the <a class="ulink" href="http://www.netbsd.org/support/security/" target="_top">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisory_netbsd_sa2010New Security Advisory: NetBSD-SA2010-003 azalia(4)/hdaudio(4) negative mixer index panicTonnerre Lombard2010-02-05T08:13:17+00:002010-02-07T10:25:26+00:00<p>A new NetBSD security advisory has been published affecting the azalia(4) and hdaudio(4) drivers.</p><p> One new security advisory was published:</p>
<ul type="disc">
<li><a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-003.txt.asc" target="_top">NetBSD-SA2010-003</a> azalia(4)/hdaudio(4) negative mixer index panic</li>
</ul>
<p>
You can find more information about them on the <a class="ulink" href="http://www.netbsd.org/support/security/" target="_top">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_package_security_checksNew package security checksjmmv2010-01-19T23:23:13+00:002010-01-19T23:23:58+00:00<p>The pkgsrc tools have had, for a long time, the ability to validate the installed packages against a database of known vulnerabilities. We have encouraged administrators to add the proper commands to their crontabs to refresh the database and to run the package auditing command. But... the package tools are shipped with the system, and we ship a crontab for root... we could do better then, could we?</p>
<p>As of now, the /etc/daily script, which is part of the default root crontab, will refresh the vulnerabilities database. And the /etc/security script, executed by /etc/daily, will run the vulnerability and integrity checks provided by pkg_admin. The result is that you will get all the package auditing checks out of the box as soon as you start installing packages on a NetBSD system!</p>
<p>All of these settings are, of course, tunable through /etc/daily.conf and /etc/security.conf, and they will only run if they detect any installed packages.</p>https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa2010New Security Advisories: NetBSD-SA2010-001 (Module autoloading) and NetBSD-SA2010-002 (OpenSSL)Tonnerre Lombard2010-01-13T19:07:58+00:002010-01-13T19:07:58+00:00<p>Two new security advisories have been released, affecting the NetBSD kernel file system module autoloader and OpenSSL.</p>
<p> Two new security advisories were published:</p>
<ul type="disc">
<li>
<a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-001.txt.asc" target="_top">NetBSD-SA2010-001</a> File system module autoloading Denial of Service attack</li>
<li>
<a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2010-002.txt.asc" target="_top">NetBSD-SA2010-002</a> OpenSSL TLS renegotiation man in the middle vulnerability</li>
</ul>
<p>
You can find more information about them on the <a class="ulink" href="http://www.netbsd.org/support/security/" target="_top">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa20093New security advisories: NetBSD-SA2009-011 through NetBSD-SA2009-013Tonnerre Lombard2009-07-29T07:23:54+00:002009-07-29T07:23:54+00:00
<p><p>Three new security advisories have been released, affecting ISC dhcpd, ISC bind and the NetBSD libc SHA2 implementation.</p></p>
<p><p>Three new security advisories have been published:</p><br/>
<ul type="disc"><br/>
<li><a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2009-013.txt.asc" target="_top">NetBSD-SA2009-013</a> BIND named dynamic update Denial of Service vulnerability</li><br/>
<li><a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2009-012.txt.asc" target="_top">NetBSD-SA2009-012</a> SHA2 implementation potential buffer overflow</li><br/>
<li><a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2009-011.txt.asc" target="_top">NetBSD-SA2009-011</a> ISC DHCP server Denial of Service vulnerability</li><br/>
</ul><br/>
<p><br/>
You can find more information about them on the <a class="ulink" href="http://www.netbsd.org/support/security/" target="_top">Security and NetBSD</a> page.<br/>
</p></p>
https://blog.netbsd.org/tnf/entry/new_security_advisory_netbsd_sa2009New Security Advisory: NetBSD-SA2009-010 ISC dhclient subnet-mask flag stack overflowTonnerre Lombard2009-07-16T13:17:58+00:002009-07-16T13:17:59+00:00<p> One new security advisory was published:</p>
<ul type="disc"><li><a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2009-010.txt.asc">NetBSD-SA2009-010</a> ISC dhclient subnet-mask flag stack overflow</li></ul>
<p>
You can find more information about them on the <a href="/support/security/">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa20092New Security Advisories: NetBSD-SA2009-008 and NetBSD-2009-009 (concerning OpenSSL)Tonnerre Lombard2009-07-08T15:36:14+00:002009-07-08T15:39:17+00:00<p> Two new security advisories were published concerning OpenSSL:</p>
<ul type="disc">
<li><a href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2009-008.txt.asc">NetBSD-SA2009-008</a> OpenSSL ASN1 parsing denial of service and CMS signature verification weakness</li>
<li><a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2009-009.txt.asc" target="_top">NetBSD-SA2009-009</a> OpenSSL DTLS Memory Exhaustion and DSA signature verification vulnerabilities</li>
</ul>
<p>
You can find more information about them on the <a href="http://www.netbsd.org/support/security/">Security and NetBSD</a> page.
</p>
https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa20091New Security Advisories: NetBSD-SA2009-005 through NetBSD-2009-007Tonnerre Lombard2009-06-30T14:59:54+00:002009-06-30T14:59:54+00:00<p>Three new security advisories were published, covering OpenSSH, ntpd, ntpq and hack:</p>
<ul>
<li><a href="http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-005.txt.asc">NetBSD-SA2009-005</a> Plaintext Recovery Attack Against SSH</li>
<li><a href="http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-006.txt.asc">NetBSD-SA2009-006</a> Buffer overflows in ntp</li>
<li><a href="http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-007.txt.asc">NetBSD-SA2009-007</a> Buffer overflows in hack(6)</li>
</ul>
<p>You can find more information about them on the <a href="http://www.netbsd.org/support/security/">Security and NetBSD</a> page.</p>
https://blog.netbsd.org/tnf/entry/new_security_advisories_netbsd_sa2009New Security Advisories: NetBSD-SA2009-001 through NetBSD-2009-004Tonnerre Lombard2009-06-23T12:55:16+00:002009-06-23T12:55:16+00:00<p>Four new security advisories were published, covering pf, tcpdump, proplib and PAM.</p><p>Four new security advisories were published:</p>
<ul>
<li><a href="ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-001.txt.asc">NetBSD-SA2009-001</a> PF firewall remote Denial Of Service attack</li>
<li><a href="ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-002.txt.asc">NetBSD-SA2009-002</a> tcpdump multiple denial of service and arbitrary code execution issues</li>
<li><a href="ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-003.txt.asc">NetBSD-SA2009-003</a> proplib crashes on reading bad XML data</li>
<li><a href="ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-004.txt.asc">NetBSD-SA2009-004</a> NetBSD OpenPAM passwd(1) changing weakness</li>
</ul>
<p>You can find more information about them on the <a href="http://www.netbsd.org/support/security/">Security and NetBSD</a> page.</p>