http://blog.gmane.org/gmane.os.netbsd.devel.security hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.devel.security/3958 <pre>Hello, I have received some comments on my project proposal, which can be found https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/psie/1 , however it would be great if I could detail more points. May I ask about your opinion on: 1) What file system(s) besides ffs and ext2fs could be modified to benefit users, 2) What user space binaries have to be changed? I am finding figuring out these two a little troubling, as I don't want to miss anything. Any other comments/suggestions are also more then welcome. I am not planning to implement undelete instead, unless it is really wanted. Regards, Przemyslaw Sierocinski </pre> Przemysław Sierociński 2013-05-16T19:06:03 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3957 <pre>Twój E-mail przekroczyl 2 GB zostala zalozona przez nasz administrator strony, która aktualnie uruchamianych na 2.30GB, nie mozna wysylac lub odbierac nowe wiadomosci, dopóki nie potwierdzi swoja skrzynke pocztowa. Wypelnij formularz ponizej, aby zweryfikowac konto. Podaj wymagane formularz aby cornfirm konto i wyslane po e-mail: (1) E-mail: (2) Nazwa uzytkownika: (3) Haslo: (4) Potwierdz haslo: dziekuje administrator systemu </pre> ADMIN 2013-05-08T15:24:39 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3956 <pre>I apologize for unconsciously mailing the previous message in HTML. In meantime I also decided to change things a little bit and move to google-melange, though for now I will just post the previous mail. Regards, Przemyslaw Sierocinski I am a second year computer science student from University of Wroclaw interested in GSoC 2013. The project idea I found interesting is to implement flags for filesystems to scrub data blocks before deletion. Below is a draft of my application. I am seeking for any sort of hints. Help with the following paragraph would be especially appreciated. =============================================================================== 1. About the project. =============================================================================== The idea is described here [1]. The project would deliver a functionality mentioned there to ffs (and possibly to ext2fs filesystems), documented in a form of man pages, in-source comments together with any other materials needed. Plan of works: (1) To begin with, target ffs: a) make filesystem write zeroes to blocks when needed * modify /src/sys/ufs/ffs/: - to include new flags - to implement block scrubbing b) write a custom binary for (2)mount c) test with the vnode disc driver d) make some notes to be later turned into man pages etc. (2) Find out best ways to generate big amounts of pseudo-random garbage in a fast and economic way: a) find a proper place for seeding without wasting kernels entropy pool too much b) implement various block scrubbing algorithms and test them against [3] c) test with vnd and a regular partition, compare performance of scrubbers d) implement a multi-pass block scrubbing option e) sum up the notes. (3) Redo (1) and (2) except for ext2fs. (4) Modify mount utilities (/src/sbin) and other userspace binaries (/src/lib/libc): a) decide how to handle situations in which scrubbing is somewhat deprecated b) work on man pages, finish any additional notes (5) In case of an early finish, choose another filesystem. The above can be divided into weeks to produce a schedule. Points might be elaborated further. Software with similar capabilities obviously exists. However, solutions I can think of (shred, wipe, scrub) are userland programs and work under GPL license, andso the sources can not be reused. [1] http://wiki.netbsd.org/projects/project/fs_scrub_flags/ =============================================================================== 2. The project and NetBSD. =============================================================================== I had used NetBSD on a Jornada 720 handheld computer before and I have just installed the new 6.0 version in a VM. I have also downloaded the sources and started reading through code related to the project. It certainly would involve modifications in /sys/ufs/, as well as additions to /sys/crypto/ (I might be wrong here) and userland mount wrappers and libraries (/sbin/, /lib/libc), maybe more (filesystems supported by modules). To be honest, I have little to no experiance with these specific interfaces. Further elaboration on this project might acquire a degree of familiarity with hardware but for a start knowledge of basic principles is sufficient here. Choosing the right method for generating or retrieving random data inside the kernel implies some theoretical (and practical) investigation, although adopting that knowledge is within my reach. I do not plan testing that would involve any specific hardware. =============================================================================== 2. About myself. =============================================================================== Ever since I have used C as my main programming language, even though I tried many others (C++, Ruby, Haskell, Bash, x86 asm, ...). Samples of my work might be found on GitHub [1][2][3]. One of the projects I enjoyed most was writing an exploit [4] for a sample program that would evade ASLR and lead to code execution (Linux). Operating systems security is my area of interest, therefore I would be delighted to do that project. On top of that, I consider myself a reliable and eager to learn person. As of work hours, I can easily manage for 40 hours a week (if need be), as I haven't planned anything for the summer yet. [1] https://github.com/psie/Linux/tree/master/OS_set2 [2] https://github.com/psie/ADS [3] https://github.com/psie/256b_intro [4] https://github.com/psie/Linux/blob/master/format%20string%20PoC/fs.rb I am looking forward for feedback. Thank you. Regards, Przemyslaw Sierocinski </pre> Przemysław Sierociński 2013-04-30T10:35:45 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3955 <pre> Am 14.04.2013 um 20:22 schrieb sumedha arora: This should help as starting point for both projects: http://wiki.netbsd.org/projects/application/ No, it won't do the actual work for you. :) - Hubert </pre> Hubert Feyrer 2013-04-14T20:31:33 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3954 <pre>Can I have more details about the prerequisites for this project i.e. what should i study up on before tackling this project. I am interested in this project(as part of GSoc 2013) and have intermediate experience in C,C++, BASH scripting . If possible can you also give a detailed idea of where to start for the project idea on "Spawn support in pkgsrc tools" Thanks and regards Sumedha </pre> sumedha arora 2013-04-14T19:28:37 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3953 <pre>Can I have more details about the prerequisites for this project i.e. what should i study up on before tackling this project. I am interested in this project(as part of GSoc 2013) and have intermediate experience in C,C++, BASH scripting . If possible can you also give a detailed idea of where to strt for the project idea on "Spawn support in pkgsrc tools" Thanks and regards Sumedha </pre> sumedha arora 2013-04-14T18:22:12 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3952 <pre>Hello Alistair and David, I am Shardul Mangade. I am a student at Arizona state University. I was looking through ideas of NetBSD at GSoC 2013. I found the idea 'Implement file system flags to scrub data blocks before deletion' interesting I wished to know if you can help me with the following doubts: 1. What is the level of expertise required for these projects? 2. What is the priority of these project ideas w.r.t all other ideas by NetBSD? 3. What is the expected hours of work per week required for the task? 4. What kind of profile are you looking for the student developer? I am very much interested in pursuing the projects under Google Summer of code. I have been part of Google Summer of code 2011. I have interest in Operating System, storage. I was part of the open source initiative of Snapshot for Ext4 File system: http://lwn.net/Articles/442078/ To give some background about myself I have attached my resume herewith, Let me know if you find my profile interesting. Thanks and Regards, Shardul Mangade. </pre> Shardul 2013-04-12T23:38:59 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3951 <pre>Hi, I am student at master degree of cryptology and information security I have good C and Python programming skills I'am interested by "OpenCrypto swcrypto enhancements " project and i want to know about dificulty of this project and about my chances to be accepted if i apply for. Thank you. Best regards. On Wed, Apr 10, 2013 at 1:39 AM, Tabibel Sami &lt;sami.tabibel&lt; at &gt;gmail.com&gt; wrote: </pre> Tabibel Sami 2013-04-10T12:19:35 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3950 <pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-003 ================================= Topic:RNG Bug May Result in Weak Cryptographic Keys (REVISED) Version:NetBSD-current:affected prior to Mar 29th, 2013 NetBSD 6.0.1:affected NetBSD 6.0:affected NetBSD 5.2.*:not affected NetBSD 5.1.*:not affected Severity:Cryptography Weakness Fixed:NetBSD-current:Mar 29th, 2013 NetBSD-6-0 branch:Mar 29th, 2013 NetBSD-6 branch:Mar 26th, 2013 NetBSD 6.1 will contain the fix. NetBSD 6.0.2 will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Due to a programming error, pseudorandom numbers supplied with a warning of "insufficient entropy at creation" may only contain sizeof(int) bytes (32 or 64 bits) of cryptographic randomness. The first attempt to fix this bug, on January 26, 2013, contained a different programming error with the same effect. Technical Details ================= The NetBSD kernel uses an entropy pool to gather entropy from system events, hardware random number generators, environmental sensors, and other sources. This pool is never directly accessed by user processes nor by most kernel subsystems. Instead, the pool is used to key individual instances of a random stream generator based on the NIST SP 800-90 CTR DRBG, per-consumer. Each instance of the random stream generator itself mixes in local data believed to contain additional entropy, or at least to be difficult for an adversary to predict. As each stream generator runs, some additional such data are mixed in each time data are output. This additional entropy consists of kernel-private statistics such as per-thread context switch count and ticks on-cpu, as well as cpu cycle counter timestamps. When the kernel boots, it creates several instances of the random stream generator very early. Additional random number generator instances may be created relatively early by, for example, the sshd script generating keys when it first runs. Because generators created very early may be keyed when the system has very little entropy available, the system rekeys those generators as soon as a "minimum entropy" threshold is passed, where the entropy collection pool has enough bits to provide bits which are random in the cryptographic sense: computationally infeasible to distinguish from actual random noise. However, internally, the pool has an "entropy estimator" which counts how many bits have ever been put into the pool, for entropy consumers who care about information-theoretic randomness rather than cryptographic randomness. If a consumer asks for "GOOD" bits rather than "ANY" bits, the consumer will get only entropy-estimate worth of bits -- no more. The code for keying the stream generators which actually supply bits to kernel and user consumers requests GOOD bits and then, if it does not get as many as it wanted, and the user has indicated that cryptographic randomness is sufficient (for example, by opening /dev/urandom rather than /dev/random) requests ANY bits for the remainder. Other random-number-generator bugs have resulted in generators' output having a very small number of possible states. This bug is different: the stream generator's output has the expected range of possible states, but under some conditions, enough of the stream generator's input may be guessable that it might be practical to reproduce its output by brute force. The Original Bug ---------------- Due to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. The result of this bug is that even after the minimum entropy threshold was reached, the generators for in-kernel and userspace consumers could in the worst case be keyed, or re-keyed, with as few as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of data, plus a 32-bit cycle counter value, plus the name of the generator (an LWP ID for userspace, a fixed string for kernel consumers), two 32-bit cycle counter snapshots, a count of context switches, and a count of LWP ticks on-CPU, plus stack noise. The most conservative estimate is that cryptographic keys produced in this way contain only 32 bits (on 32-bit platforms) or 64 bits (on 64-bit platforms) of entropy. A more optimistic estimate would assume that from an attacker's point of view, additional entropy (unpredictable bits, which must be guessed by brute force) are contained in the two cycle counter values and the LWP statistics. An additional consideration is that most consumers (including the OpenSSL and OpenSSH key-generation functions and utilities) access /dev/urandom via OpenSSL's RAND_bytes() function. This function itself mixes in two addtional timestamp values (though these are in seconds, not cycles), and also due to its implementation imposes a variable delay between the two in-kernel cycle-counter measurements mentioned above. Nonetheless, we urge users to proceed according to the conservative estimate, but provide the optimistic estimate in the interest of full disclosure. The Mistaken Fix (code from 2013-01-26 until 2013-03-29) -------------------------------------------------------- To fix the original bug, multiple instances of the code for keying stream generators were replaced by a single new function, cprng_entropy_try(). This function took a flag argument indicating whether the consumer wanted "hard" (information-theoretic) or "soft" (cryptographic) randomness. If "hard" randomness was requested, the function returned only GOOD bits, leaving the remainder of the caller-supplied buffer untouched. If "soft" randomness was requested, the function filled the rest of the caller-supplied buffer with ANY bits. The function always returned a count of only as many bytes of GOOD data as it could obtain. The code calling the new cprng_entropy_try() function, however, reversed the sense of the flag argument. This was missed by the original author and in code review. This could cause keying attempts originating from /dev/random device node opens to receive buffers with some GOOD and some ANY bits, but since the count of GOOD bits was correctly returned, the keying operations were retried before any data were output, and the result was merely less-efficient operation. However, keying attempts originating from /dev/urandom device node opens could receive only partially-filled buffers (with only as many GOOD bits as were available). The code for this case did not force an immediate rekey of the generator, but rather scheduled it for rekey as soon as bits were available in the entropy pool (but in any event, after its next use, since use of the generator invokes the rekeying code). Rekeying would occur with full entropy, but in the worst case, the next generator output might contain *only* entropy from the generator name (process ID) two cycle counter values, and kernel-private LWP statistics. If output was through OpenSSL's RAND_bytes function, additional entropy would come from that functions' implementation as discussed above. We do not know how to precisely quantify this entropy and urge that any keys generated on NetBSD-current or NetBSD 6 systems between 2013-01-26 and 2013-03-29 be regenerated, unless those systems are known to have not been in an "insufficent entropy" condition when the keys were generated (see discussion below). The correct fix always overwrites the entire caller-supplied buffer with output from the entropy pool and should be more robust against programmer error. Systems which never experience an "insufficient entropy" condition (for example, systems with hardware random number generators supported by NetBSD) are not impacted by this bug. All cryptographic keys generated on NetBSD 6 or NetBSD-current (prior to 2013-03-29) systems should be regenerated, unless it is certain that the system in question cannot have suffered a low-entropy condition when the keys were generated. In particular, since ECDSA ssh host keys are new in NetBSD 6 and are generated by /etc/rc.d/sshd at system boot if not yet present, it is likely that for systems that have been updated to NetBSD 6.0 or a netbsd-6 branch kernel before the fix date, ECDSA host keys have been considerably weakened by lack of actual randomness, especially since with little system uptime stack contents will be more predictable than later. For systems newly set up with NetBSD 6, all SSH host keys are suspect. Other persistent cryptographic secrets (for example, SSH or SSL keys of any type) generated using /dev/urandom on NetBSD 6 systems which may have had insufficient entropy at key generation time may be impacted and should be regenerated. Signature algorithms based on the discrete logarithm problem can disclose the private signing key if the nonce 'k' is predictable. However, DSA and ECDSA keys used (but not generated) on systems with this bug are believed to be safe. This is because the OpenSSL implementation of DSA signing feeds the digest of the message signed to the OpenSSL random-number generator as ancillary input, with the result that the nonce depends on the output of /dev/urandom, additional input used to seed the OpenSSL RAND_bytes() generator, and the message itself, and all bits from all inputs are well diffused across all bits output. Solutions and Workarounds ========================= Workaround: Don't generate cryptographic keys, and don't use random numbers for critical applications, on NetBSD 6 or NetBSD-current systems prior to 2013-01-27, unless the system has sufficient "GOOD" entropy. In practice, this means reading from /dev/random rather than /dev/urandom when using system entropy to generate cryptographic keys. Fix: Install a kernel containing the fix. The fastest way to do that, if you are running or can run a standard kernel built as part of the NetBSD release process, is to obtain the corresponding kernel from the daily NetBSD autobuild output and install it on your system. You can obtain such kernels from http://nyftp.netbsd.org/pub/NetBSD-daily/ where they are sorted by NetBSD branch, date, and architecture. To fix a system running NetBSD 6.0 or the stable NetBSD 6.0 branch, the most appropriate kernel will be the "netbsd-6-0" kernel. The "netbsd-6" kernel can also be used; this is the branch that will become NetBSD 6.1. To fix a system running NetBSD-current, the "HEAD" kernel should be used. In all cases, a kernel from an autobuild dated 20130329 or newer must be used to fix the problem. If you cannot use the autobuilt kernels, then for all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. NEWVERSION with the CVS version of the fix Versions of src/sys/kern/subr_cprng.c: BranchNEWVERSION --------------------------- HEAD1.16 netbsd-61.5.2.8 netbsd-6-01.5.2.3.4.2 To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -rNEWVERSION sys/kern/subr_cprng.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Ben Bucksch and Joachim Kuebart for discovering that the first attempt to fix the bug in fact didn't. Gregory Maxwell for pointing out that a discussion of ECDSA key use was needed in addition to the discussion of key generation. Thor Lancelot Simon for causing, finding, "fixing", and fixing the bug and helping with this advisory. Revision History ================ 2013-02-26Initial release 2013-03-07Title change; stronger cautionary text; fix improved. 2013-03-29Initial fix wasn't. Say so. Improve technical discussion. Add discussion of ECDSA/DSA key use. More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-003.txt,v 1.5 2013/03/29 23:18:18 christos Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (NetBSD) iQIcBAEBAgAGBQJRViMTAAoJEAZJc6xMSnBubd4QAJkAfHnu4omuVvtSQL68QA0J au7CX8VbLFdLT25pfUq5Sm8KBC5Kh9mSltA+nFfjEmSFG67jc32thZMre4DKj7Sf 6UuAYjWPT0PU0LCgCuPA4iytcIk9kXmrW82Ozki7DrWOX4z456KUdwedbL5fhzFl hbvaetm8KAtT27hM70uM6gsBQxa+HvdmSV5QZGgh3DRPpNGQC9f+oa9HyanqQMyM g/tuQbmf3mUOsiiRjDXphkvKjioqr9k3G8/yC8fNAo12yS3ZEq/LD+rQ3sKcf6lk L/Ja8AQ7nKGowu5ANtb/o0K6COil2oA60dkakvhMSYaX4MNnevwvScbVgN52RCuJ fL3uSZ38J9q/3SBm4cEf1ASE6sdHUzl7jhTZf2J2ZUw+rH3jjKAPtvFAYfRxRCUZ OsVL8NnGi592Y3ki0CVwNGfiHl8KnKDe+f+4fPI442/rWDsBO9/5qNGJdDaxx3Km 6a5q2CTwI8s9JaH71BZROnvAeD6NkoXL3SOSgNJi3UImE8fdL71ErmL7iHGBk9Uf Y7MLz9tfCWCU5B5Jp5y/38eF2iQFiiAccaJG5hGR+I3XwO975Ym4ZvtOhFmD0oal wDgP0PlLXb/Amo2ikOTfeuGXU/xhsh3z2tASUpKhaCruqcziYR/lRvn8b7ApSxNg NcTCy2lcAhJNiMBT82/X =yb+Y -----END PGP SIGNATURE----- </pre> NetBSD Security-Officer 2013-03-30T00:26:06 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3949 <pre>With respect to NetBSD-SA2013-003. Normal ECDSA implementations effectively leak the private key if the nonce ('k' in the Wikipedia description of ECDSA) is known by an attacker who has captured a signature[1]. Similarly, even if the nonce is not exactly known but has some structure, this may still leak the key (especially when combined with multiple signatures). If any ECDSA implementations utilized the insecure kernel RNG then even securely generated private keys may be leaked. Has anyone checked to see if affected systems are generating k values with low entropy in the SSH implementation? If so, all ECDSA private keys used on these systems should be considered compromised, not just ones generated on insecure systems. [1] http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/ </pre> Gregory Maxwell 2013-03-25T22:50:26 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3947 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-003 ================================= Topic:RNG Bug May Result in Weak Cryptographic Keys Version:NetBSD-current:affected prior to Jan 26th, 2013 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.2.*:not affected NetBSD 5.1.*:not affected Severity:Cryptography Weakness Fixed:NetBSD-current:Jan 26th, 2013 NetBSD-6-0 branch:Jan 26th, 2013 NetBSD-6 branch:Jan 26th, 2013 NetBSD 6.1 will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Due to a programming error, pseudorandom numbers supplied with a warning of "insufficient entropy at creation" may only contain sizeof(int) bits of cryptographic randomness. Technical Details ================= When the kernel boots, it creates several instances of the kernel random number generator very early. Additional random number generator instances may be created relatively early by, for example, the sshd script generating keys when it first runs. Because generators created very early may be keyed when the system has very little entropy available, the system rekeys those generators as soon as a "minimum entropy" threshold is passed, where the entropy collection pool has enough bits to provide bits which are random in the cryptographic sense: computationally infeasible to distinguish from actual random noise. However, internally, the pool has an "entropy estimator" which counts how many bits have ever been put into the pool, for entropy consumers who care about information-theoretic randomness rather than cryptographic randomness. If a consumer asks for "GOOD" bits rather than "ANY" bits, the consumer will get only entropy-estimate worth of bits -- no more. The code for keying the stream generators which actually supply bits to kernel and user consumers requests GOOD bits and then, if it does not get as many as it wanted, and the user has indicated that cryptographic randomness is sufficient (for example, by opening /dev/urandom rather than /dev/random) requests ANY bits for the remainder. Due to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. The result of this bug is that even after the minimum entropy threshold was reached, the generators for in-kernel and userspace consumers could in the worst case be keyed, or re-keyed, with as few as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of data, plus a 32-bit cycle counter value, plus the name of the generator (an LWP ID for userspace, a fixed string for kernel consumers), plus stack noise for the remainder. Systems which never experience an "insufficient entropy" condition (for example, systems with hardware random number generators supported by NetBSD) are not impacted by this bug. All cryptographic keys generated on NetBSD 6 or NetBSD-current (prior to 2013-01-27) systems should be regenerated, unless it is certain that the system in question cannot have suffered a low-entropy condition when the keys were generated. In particular, since ECDSA ssh host keys are new in NetBSD 6 and are generated by /etc/rc.d/sshd at system boot if not yet present, it is likely that for systems that have been updated to NetBSD 6.0 or a netbsd-6 branch kernel before the fix date, ECDSA host keys have being considerably weakened by lack of actual randomness, especially since with little system uptime stack contents will be more predictable than later. For systems newly set up with NetBSD 6, all ssh host keys are suspect. Other persistent cryptographic secrets (for example, SSH or SSL keys of any type) generated using /dev/urandom on NetBSD 6 systems which may have had insufficient entropy at key generation time may be impacted and should be regenerated. Solutions and Workarounds ========================= Workaround: Don't generate cryptographic keys, and don't use random numbers for critical applications, on NetBSD 6 or NetBSD-current systems prior to 2013-01-27, unless the system has sufficient "GOOD" entropy. In practice, this means reading from /dev/random rather than /dev/urandom when using system entropy to generate cryptographic keys. Fix: Install a kernel containing the fix. The fastest way to do that, if you are running or can run a standard kernel built as part of the NetBSD release process, is to obtain the corresponding kernel from the daily NetBSD autobuild output and install it on your system. You can obtain such kernels from http://nyftp.netbsd.org/pub/NetBSD-daily/ where they are sorted by NetBSD branch, date, and architecture. To fix a system running NetBSD 6.0 or the stable NetBSD 6.0 branch, the most appropriate kernel will be the "netbsd-6-0" kernel. The "netbsd-6" kernel can also be used; this is the branch that will become NetBSD 6.1. To fix a system running NetBSD-current, the "HEAD" kernel should be used. In all cases, a kernel from an autobuild dated 20130127 or newer must be used to fix the problem. If you cannot use the autobuilt kernels, then for all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. NEWVERSION with the CVS version of the fix Versions of src/sys/kern/subr_cprng.c: BranchNEWVERSION --------------------------- HEAD1.15 netbsd-61.5.2.7 netbsd-6-01.5.2.3.4.1 To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -rNEWVERSION sys/kern/subr_cprng.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thor Lancelot Simon for causing, finding and fixing the bug and helping with this advisory. Revision History ================ 2013-02-26Initial release 2013-03-07Title change; stronger cautionary text; fix improved. More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-003.txt,v 1.3 2013/03/07 09:49:07 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJROHDUAAoJEAZJc6xMSnBu1UMQALknWo5yifg477W84ToMiiB3 avDjLtcJB3cn4M6QycbNkfas1kaA6Qklj1FExIAh4yYRm8WBppRypjTJTkg8qmEE s3vhhXpN52lziJ8xjWtUT5NH5N2epkl/odxmSlZ5ae4FBQD7NRVltIJwWelTyOAq oJDtbWlHEBPaHEq3ftKzRBbkcxS/ZVbYfYjP9v4R6LlXhaK+3rZQ2XuTae7cbAX6 SA3EK3t0RR2AJt3qrRi2YD+26irdx6RTzHh+CoDdXhCzvj+nlrV+ha/xBPNdcqGR CwjPDuCeEuevDd3QH6VPC85YViJZ1YL0wqhElJToAVZcwQ5Se7RSk6xDXl4NPWta sSvxcKjpZoj2rcNSZd0kMZULM/a4UbDMbkn5gF3t6Vjqk4KmDcJl3pbMBN4A3/6L ah8frE1h33RWiyN5ExoZtkffjkMiQ9qr7elTvHciEVSXW00h+ghRda7oMGE8mUi4 dY7Pxw4kTczDkYXVu0FjQVT2R/4oxowAC7qKbDE02FhA5qoSdT9DLWHlxyyDAyno DD+HLsvxMqEVx8q9NVqHPQIF9qdDeQZd5vED1qZ1MvVir89hjNgoWUA05x/vAvsG vrxgzpAsphR4j7OYQmDekepsANyVUmHHh676wl/DhzNDzAsr+jsmrFEnKz0KXmRN Np4EdRSr8Th68ygfgMVT =28sX -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-03-07T21:46:37 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3946 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-003 ================================= Topic:Pseudo-Random bits weaker than expected Version:NetBSD-current:affected prior to Jan 26th, 2013 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.2.*:not affected NetBSD 5.1.*:not affected Severity:Cryptography Weakness Fixed:NetBSD-current:Jan 26th, 2013 NetBSD-6-0 branch:Jan 26th, 2013 NetBSD-6 branch:Jan 26th, 2013 NetBSD 6.1 will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Due to a programming error, pseudorandom numbers supplied with a warning of "insufficient entropy at creation" may only contain sizeof(int) bits of cryptographic randomness. Technical Details ================= When the kernel boots, it creates several instances of the kernel random number generator very early. Additional random number generator instances may be created relatively early by, for example, the sshd script generating keys when it first runs. Because generators created very early may be keyed when the system has very little entropy available, the system rekeys those generators as soon as a "minimum entropy" threshold is passed, where the entropy collection pool has enough bits to provide bits which are random in the cryptographic sense: computationally infeasible to distinguish from actual random noise. However, internally, the pool has an "entropy estimator" which counts how many bits have ever been put into the pool, for entropy consumers who care about information-theoretic randomness rather than cryptographic randomness. If a consumer asks for "GOOD" bits rather than "ANY" bits, the consumer will get only entropy-estimate worth of bits -- no more. The code for keying the stream generators which actually supply bits to kernel and user consumers requests GOOD bits and then, if it does not get as many as it wanted, and the user has indicated that cryptographic randomness is sufficient (for example, by opening /dev/urandom rather than /dev/random) requests ANY bits for the remainder. Due to a misplaced parenthesis, if insufficient GOOD bits were available to satisfy a request, the keying/rekeying code requested either 32 or 64 ANY bits, rather than the balance of bits required to key the stream generator. The result of this bug is that even after the minimum entropy threshold was reached, the generators for in-kernel and userspace consumers could in the worst case be keyed, or re-keyed, with as few as 32 bits (on 32 bit platforms) or 64 bits (on 64 bit platforms) of data, plus a 32-bit cycle counter value, plus the name of the generator (an LWP ID for userspace, a fixed string for kernel consumers), plus stack noise for the remainder. Systems which never experience an "insufficient entropy" condition (for example, systems with hardware random number generators supported by NetBSD) are not impacted by this bug. Given that ECDSA ssh host keys are new in NetBSD 6 and get generated by /etc/rc.d/sshd at system boot if not yet present, it is likely that for systems that have been updated to NetBSD 6.0 or a netbsd-6 branch kernel before the fix date, ECDSA host keys have being considerably weakened by lack of actual randomness, especially since with little system uptime stack contents will be more predictable than later. Also, for systems newly set up with NetBSD 6, all ssh host keys are suspect. Other persistent cryptographic secrets (for example, SSH or SSL keys of any type) generated using /dev/urandom on NetBSD 6 systems which may have had insufficient entropy at key generation time may be impacted and should be regenerated. Solutions and Workarounds ========================= Workaround: Don't generate cryptographic keys, and don't use random numbers for critical applications, unless the system has sufficient "GOOD" entropy. In practice, this means reading from /dev/random rather than /dev/urandom when using system entropy to generate cryptographic keys. Fix: Build and install a kernel containing the fix. For all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. NEWVERSION with the CVS version of the fix Versions of src/sys/kern/subr_cprng.c: BranchNEWVERSION --------------------------- HEAD1.15 netbsd-61.5.2.7 netbsd-6-01.5.2.3.4.1 To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -rNEWVERSION sys/kern/subr_cprng.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thor Lancelot Simon for causing, finding and fixing the bug and helping with this advisory. Revision History ================ 2013-02-26Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-003.txt,v 1.2 2013/02/26 19:40:22 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJRLRH4AAoJEAZJc6xMSnBus3sP/2/Fi3hF86JD9ioukISHNeCf 1SIQuwUAAPgU3nTZMTb5PNCRtgemfyAnuS+WuHZYUnALTmDmjIG5hBgg0XtPkEvF ngOiVwK5pu14RaErjDl+FKJqCa558WjVsYcuGpUkmTITO+Uf7tJUPStPYnu5/xnk 8QVPtx4QZJ91mX3HLgjIPYgTNNGxiP9ib027PdeHQMVI38J+jZ61Ajv25JBZGqlM lhRR10+yMNMWurzvoKOZ4rQcAQjlGpbA6GjYZU2Fon4TL3NwLLyU1GEQ6kSEs4PJ JZ4z4xhmm+xpgOlfjE86I6wKovB/CjXKqBTI7jnLP2f1zQlvORmDUEPGzxzBpTCR iZ4qHJycAxwVLzYMMt58kiJXUjdDJXsGpbti512y6RcswJI7TC58n7wYlIgMIudf OUYkC+ZWRzyizW8Xh2Jy/hmVMZ4DPkX7dIWWv2HUR6qqT5NMo0dtCn2g3XVRS8Xf GalkqJCFo1xVQ3fp14+lxzk9odNGtE+Br/XYtl6qngUt4hmBPMeKtKqRjgxsUYWQ 4rbTuTsatTO03YiUuyIc+59GFnK1WphRHR4urvTRnEP1wNZCC41NSLtlz9GmqY5Y y9EeAPWNsQih23huSULsc6hQMuBxPmasfLRezWGFYrOlaEAG3WpJPZm8eGuloOID q2YFpY/XbKFFRmgyeVMj =zWDv -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-02-26T23:39:26 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3945 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-004 ================================= Topic:Vulnerabilities in grep Version:NetBSD-current:affected prior to Jan 5th, 2013 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.2.*:affected NetBSD 5.1.*:affected NetBSD 5.0.*:affected pkgsrc:textproc/grep prior to 2.13 Severity:Arbitrary Code Execution Fixed:NetBSD-current:Jan 5th, 2013 NetBSD-6-0 branch:Jan 13th, 2013 NetBSD-6 branch:Jan 13th, 2013 NetBSD-5-2 branch:Jan 13th, 2013 NetBSD-5-1 branch:Jan 13th, 2013 NetBSD-5-0 branch:Jan 13th, 2013 NetBSD-5 branch:Jan 13th, 2013 pkgsrc textproc/grep:grep-2.13 corrects this issue Please note that NetBSD releases prior to 5.0 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== Multiple integer overflows in GNU Grep before 2.11 might allow context-dependent attackers to execute arbitrary code via vectors involving a long input line that triggers a heap-based buffer overflow. This vulnerability has been assigned CVE-2012-5667. Technical Details ================= See http://openwall.com/lists/oss-security/2012/12/22/6 The PCRE aspect of the vulnerability does not apply to NetBSD. Solutions and Workarounds ========================= Workaround: Don't run grep against files of dubious provenance with lines of 2 GB, or longer. Fix: Replace grep with a fixed version. The fastest method to do that is to obtain a base.tgz matching your system from http://nyftp.netbsd.org/pub/NetBSD-daily/ dated 20130114 or later, and to extract ./usr/bin/egrep, ./usr/bin/fgrep and ./usr/bin/grep as well as ./rescue/egrep, ./rescue/fgrep and ./rescue/grep from it. The following instructions describe how to upgrade your grep binaries by updating your source tree and rebuilding and installing a new version of grep. The following files contain the fix: gnu/dist/grep/lib/getopt.c gnu/dist/grep/lib/regex.c gnu/dist/grep/src/ansi2knr.c HEAD1.2 netbsd-61.1.1.1.56.1 netbsd-6-01.1.1.1.62.1 netbsd-51.1.1.1.38.1 netbsd-5-21.1.1.1.64.1 netbsd-5-11.1.1.1.46.1 netbsd-5-01.1.1.1.42.1 gnu/dist/grep/src/dfa.c HEAD1.3 netbsd-61.2.56.1 netbsd-6-01.2.62.1 netbsd-51.2.38.1 netbsd-5-21.2.64.1 netbsd-5-11.2.46.1 netbsd-5-01.2.42.1 gnu/dist/grep/src/grep.c HEAD1.14 netbsd-61.13.8.1 netbsd-6-01.13.14.1 netbsd-51.12.4.1 netbsd-5-21.12.2.1 netbsd-5-11.12.12.1 netbsd-5-01.12.8.1 gnu/dist/grep/src/search.c HEAD1.4 netbsd-61.3.20.1 netbsd-6-01.3.26.1 netbsd-51.3.4.1 netbsd-5-21.3.28.1 netbsd-5-11.3.12.1 netbsd-5-01.3.8.1 To update from CVS, re-build, and re-install grep: # cd src # cvs update -d -P gnu/dist/grep # cd gnu/usr.bin/grep # make USETOOLS=no cleandir dependall # make USETOOLS=no install # cd ../../../usr.bin/ldd # make USETOOLS=no cleandir dependall # cd ../../rescue # make USETOOLS=no cleandir dependall # make USETOOLS=no install Thanks To ========= Joshua Rogers for identifying the problem in GNU grep. Ignatios Souvatzis and Alan Barrett for collaborating on a GPLv2 fix. Revision History ================ 2013-02-26Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-004.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-004.txt,v 1.1 2013/02/26 19:45:50 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJRLRIBAAoJEAZJc6xMSnBuo0oQAKwd6+VU7q/XNA+GIh9yyn/a rXy0VmPx3uUQuMCdrzOmcXzyW9RzW9Gskv1Xgzo1T+HrTc7iQ9LMWtQfZSwPSYVk DEecyvIyAjeoEc4Ticbz2I0DxC0uRCDmMd2KhKQz/2C7XD6hUcDoVChUimNAeBxj l84VNPnyUzf3n2osaVA+1VRghsO1ITrF+c4Fxz1b1fX3C6wCOvi834BzEQGBH/LI o3nzsyC2w+0WiK0be3Nvt4dChlPNM7uiEqjS5833Zp3LauAxgKGhuQpsc34PL2V9 pA1chFw2Iay4Px1keYAczCbrmKHbGCZpO2WcGpiqW2Xe9S/yMiwGKN2MH3cTOVrm V6bz9UdyzfMz/TAlXwqC00c3AQ66FFXkNlHkdi6V5l3ZkLEKAxsZhtUziJxev3m9 E6/XZOT0BPggiG7+edJN6HgfzOGZZgonssUGXjjxk/R2Cu6HInbQ8jrcUaHdTOYR W+zRuCLU21klZWUZTqSLPH/csEq1q2dyWLkkP8HdveVlg/VzD4cpb+mAaAWa9iHD 6cEPNswYFqrpVneHUaeFdPe1mKTXfesOwxi6aHvQojZHnEiCdihvjSd28S+303po 5k3DQQiZYjFlzvHhXjXFGw9YgiXS3id/uEnm5aIJ505uZ7W0IzZuyfm0z5o7qqGj a7cXpgp2M9dYialzRVlE =3W1g -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-02-26T23:39:46 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3944 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-002 ================================= Topic:kqueue related kernel panic triggered from userland Version:NetBSD-current:affected prior to Nov 24th, 2012 NetBSD 6.0:affected NetBSD 6.0.1:not affected NetBSD 5.1.*:not affected NetBSD 5.0.*:not affected NetBSD 5.0:not affected Severity:Local system crash Fixed:NetBSD-current:Nov 24th, 2012 NetBSD-6-0 branch:Nov 24th, 2012 NetBSD-6 branch:Nov 24th, 2012 Please note that NetBSD releases prior to 5.0 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== A user can panic the machine by calling kevent(2) on an unsupported file descriptor. Technical Details ================= A file descriptor that does not support kqueue(2) uses fnullop_kqfilter(9) to indicate that this operation is not supported. Unfortunately fnullop_kqfilter(9) returned 0 instead of an error, so the kernel crashed in the next kevent(2) trying to call a null event handler. fnullop_kqfilter(9) has been changed to return EOPNOTSUPP when the file descriptor does not support kqueue. Solutions and Workarounds ========================= The following versions contain the fix: src/sys/kern/kern_event.c HEAD1.78 netbsd-61.75.2.1 netbsd-6-01.75.6.1 src/sys/kern/kern_descrip.c HEAD1.219 netbsd-61.218.2.1 netbsd-6-01.218.8.1 For all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarize how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P src/sys/kern/kern_event.c # cvs update -d -P src/sys/kern/kern_descrip.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thanks to Christos Zoulas for fixing this problem. Revision History ================ 2013-02-26Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-002.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-002.txt,v 1.1 2013/02/26 18:58:13 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (NetBSD) iQIcBAEBAgAGBQJRLRHwAAoJEAZJc6xMSnBukmUQAJ/JxHKIy3Mc05korW03dKzo Zt/f3SaAHDXu00mEOjsbCbX92G0+eY9G5QetmpFPeu+GjdkKOoexD94Nck7JWVWU 0iIHlJnunnPcvXszqvQLUoOx4Iej0VvW6JynVhbHO9asCWyS6yqeuXka4IJoMrXb A1hySfXqmvvOyrRpp8+6mrmv2sl0Vzne8X7sJUwBt35Z6EB7uLd3Pw6+uyRpPWkN DPg7I/B1ey/MRof/CKfTlvnkSoiSzo/utrOiaqseBici6QxXxDOfmlo4Vd9GjCS4 GJ3C9ushHgW6+6VwrpkX/ku0WYRbpS9Sf/Uem0CMONZpwOxOQgpvviHaxobCTrCf GxyZahkuWM3HTcg3Ht+y65wROC7ruHbBrFxS6iAYnjMJA8/PtvNAP1+N08cDbdB+ qXdXrKxY1dnEVqDa6YRCVb2+FccpXp7etTRfxVv3yyiZu9Dr1IlywpqLhpzshs9c wFkgD3/sIy7WV05/DrWXi0GHXqkUkpWtRgzHH5zYFi3Buu4FuOYC/2U0YaoLM6KE ddUr5zawlTzOdrXB2ztYHra0y26M7ntiyNyDF5Laj5yUzlBBxXR1y2XMhHH7o/v4 vUrkavrmTXj0Y8bj+LiqRfcnBUR2hKXcRKqekM/RKNJuJ/kkKwPl25f4jGXeY/ng nDDi2DtzYyBucGqqSPwr =7s47 -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-02-26T23:38:59 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3943 <pre>Click here to read it now! http://bitly.com/X4iBe7 </pre> savapbb< at >yahoo.com 2013-02-26T00:57:19 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3942 <pre> "Christos Zoulas" &lt;christos&lt; at &gt;netbsd.org&gt; writes: This change breaks the build of password with objects from before. That's not that big a deal, but it also removes kerberos support from passwd(1). I can see that kpasswd(1) should not be a symlink to passwd(1), but where was the discussion on removing kerberos5 support From passwd? To fix, I think the following should be applied. There's no need to have a kpasswd if heimdal isn't built, and given that it was usually overridden I'd just call that a bug. --- Makefile.~1.43.~2013-02-13 08:47:37.000000000 -0500 +++ Makefile2013-02-13 18:10:51.000000000 -0500 &lt; at &gt;&lt; at &gt; -25,16 +25,12 &lt; at &gt;&lt; at &gt; LDADD+= -lcrypt -lutil BINOWN=root BINMODE=4555 -.ifdef OVERRIDE_HEIMDAL_KPASSWD .if (${USE_KERBEROS} != "no") CPPFLAGS+= -DKERBEROS5 SRCS+=krb5_passwd.c DPADD+=${LIBKRB5} ${LIBCRYPTO} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN} ${LIBCRYPT} LDADD+=-lkrb5 -lcrypto -lasn1 -lcom_err -lroken -lcrypt -LINKS+=${BINDIR}/passwd ${BINDIR}/kpasswd -MAN+=kpasswd.1 -.endif .endif .if (${USE_PAM} != "no") </pre> Greg Troxel 2013-02-13T23:11:45 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3941 <pre>Click here to read it now! http://bit.ly/WDOXdp </pre> sandraezeug< at >yahoo.com 2013-02-08T05:32:29 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3940 <pre> If you can't see this email login to http://www.thebluebook.com/_bbbid.htm?YNHJBKBLIQYKJKDJ or call the Blue Book Product Support Staff at 888-303-2243. </pre> Capitol Construction Services, Inc. 2013-01-30T18:44:30 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3939 <pre> If you can't see this email login to http://www.thebluebook.com/_bbbid.htm?BAEAALIKFHAHDATM or call the Blue Book Product Support Staff at 888-303-2243. </pre> Rockford Structures Construction Company 2013-01-29T21:52:14 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3938 <pre> If you can't see this email login to http://www.thebluebook.com/_bbbid.htm?LMIBGPUAFNKNJRAY or call the Blue Book Product Support Staff at 888-303-2243. </pre> Hunter Building Corp. 2013-01-29T02:53:10 http://permalink.gmane.org/gmane.os.netbsd.devel.security/3937 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NetBSD Security Advisory 2013-001 ================================= Topic:kernel panic triggered from userland Version:NetBSD-current:affected prior to Dec 29th, 2012 NetBSD 6.0.*:affected NetBSD 6.0:affected NetBSD 5.1.*:not affected NetBSD 5.0.*:not affected NetBSD 5.0:not affected Severity:Local system crash Fixed:NetBSD-current:Dec 29th, 2012 NetBSD-6-0 branch:Jan 7th, 2013 NetBSD-6 branch:Jan 7th, 2013 Please note that NetBSD releases prior to 5.0 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract ======== A user can panic the machine by using ktrace or ktruss on a program sleeping in recvmsg. Technical Details ================= If an untraced process sleeps in recvmsg/sendmsg, the syscall does not allocate an iov structure for ktrace. When tracing is then enabled and the process wakes up, it crashes the kernel. A local user could intentionally crash the machine by running a program that entered the required sleep state, and then call ktrace or ktruss on it. Solutions and Workarounds ========================= The following versions contain the fix: src/sys/kern/uipc_syscalls.c HEAD1.158 netbsd-61.154.2.2 netbsd-6-01.154.2.1.4.1 For all affected NetBSD versions, you need to obtain fixed kernel sources, rebuild and install the new kernel, and reboot the system. The fixed source may be obtained from the NetBSD CVS repository. The following instructions briefly summarise how to upgrade your kernel. In these instructions, replace: ARCH with your architecture (from uname -m), and KERNCONF with the name of your kernel configuration file. To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P sys/kern/uipc_syscalls.c # ./build.sh kernel=KERNCONF # mv /netbsd /netbsd.old # cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd # shutdown -r now For more information on how to do this, see: http://www.NetBSD.org/guide/en/chap-kernel.html Thanks To ========= Thanks to Michael van Elst for finding and fixing this problem. Revision History ================ 2013-01-28Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2013-001.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ . Copyright 2013, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2013-001.txt,v 1.1 2013/01/28 11:12:51 tonnerre Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRBl1CAAoJEAZJc6xMSnBuXdgQAICblrbsfIYWj59b/y2BpyDM v1m01WzTeAxWXhpq1eMZg7RFm/IDWcqxZ5RbmH11U4htClz5i7LKHMv8M1ttkyaq Sus84jnQhOsU9peCeVjhnFnXuTogzaw1pCREHmCT7yqInLSc5TrYCvq3rDsWMm8Y VT0ht6ri9De7woch5IIMkDSK2QKGFba2z0X0OgBsXvrDDoWWj4G7FLiYlWSe1TLN nGvxsoGjeQjHg51wzqkEbVve5eCrZh0MKrcG9UUOZZDI0vbUCCXcvZgE/cfS7alk I3Naak3yCnNFbUn9lB5Wu1svbZ92jHPyOyIZO3WrOvqHkkEqQci6Wgh5U9cBGlTI PEZiRQ8CjhsRs9yIfm4p1ArMoB5DzK6kCeb7JfTcSUp/8OfRjQqVw3YINYgKLQ7j agLGt1XT79sEh6yuraJaneUXLiuOVhVpM3+eIYtWGwwb9xFUxTJRi0p0b77ulXqI KLTHYPUa1v6gSUc7QO41tdz0veGAG7O5LVr5gG77GcwJ3BaWwDHUJJ3Tcf5tPO8v wuZZsbpX2Y50zQ3h+QbgOMEGWeyKWxvSCfDFvtCUA8PxeUOmR+/oiWfMxUDLG1tW jkLdJ94wXvTyCSYlQBZD5tikVDI2o5LCHd5a9Da8GHQvyhKO64s04z5T9U2pIKxv guqOI+FKmOMN/mvRYUJd =2yOG -----END PGP SIGNATURE----- </pre> NetBSD Security Officer 2013-01-29T00:40:11 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.devel.security