FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-09:15.sslSecurity Advisory The FreeBSD Project Topic: SSL protocol flaw Category: contrib Module: openssl Announced: 2009-12-03 Credits:Marsh Ray, Steve Dispensa Affects:All supported versions of FreeBSD. Corrected: 2009-12-03 09:18:40 UTC (RELENG_8, 8.0-STABLE) 2009-12-03 09:18:40 UTC (RELENG_8_0, 8.0-RELEASE-p1) 2009-12-03 09:18:40 UTC (RELENG_7, 7.2-STABLE) 2009-12-03 09:18:40 UTC (RELENG_7_2, 7.2-RELEASE-p5) 2009-12-03 09:18:40 UTC (RELENG_7_1, 7.1-RELEASE-p9) 2009-12-03 09:18:40 UTC (RELENG_6, 6.4-STABLE) 2009-12-03 09:18:40 UTC (RELENG_6_4, 6.4-RELEASE-p8) 2009-12-03 09:18:40 UTC (RELENG_6_3, 6.3-RELEASE-p14) CVE Name: CVE-2009-3555 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.FreeBSD.org/. I. Background The SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols provide a secure communications layer over which other protocols can be utilized. The most widespread use of SSL/TLS is to add security to the HTTP protocol, thus producing HTTPS. FreeBSD includes software from the OpenSSL Project which implements SSL and TLS. II. Problem Description The SSL version 3 and TLS protocols support session renegotiation without cryptographically tying the new session parameters to the old parameters. III. Impact An attacker who can intercept a TCP connection being used for SSL or TLS can cause the initial session negotiation to take the place of a session renegotiation. This can be exploited in several ways, including: * Causing a server to interpret incoming messages as having been sent under the auspices of a client SSL key when in fact they were not; * Causing a client request to be appended to an attacker-supplied request, potentially revealing to the attacker the contents of the client request (including any authentication parameters); and * Causing a client to receive a response to an attacker-supplied request instead of a response to the request sent by the client. IV. Workaround No workaround is available. V. Solution NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate SSL / TLS session parameters. As a result, connections in which the other party attempts to renegotiate session parameters will break. In practice, however, session renegotiation is a rarely-used feature, so disabling this functionality is unlikely to cause problems for most systems. Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, 7-STABLE, or 8-STABLE, or to the RELENG_8_0, RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3, 6.4, 7.1, 7.2, and 8.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-09:15/ssl.patch # fetch http://security.FreeBSD.org/patches/SA-09:15/ssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/secure/lib/libcrypto # make obj make depend make includes make make install NOTE: On the amd64 platform, the above procedure will not update the lib32 (i386 compatibility) libraries. On amd64 systems where the i386 compatibility libraries are used, the operating system should instead be recompiled as described in URL:http://www.FreeBSD.org/handbook/makeworld.html VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - - RELENG_6 src/crypto/openssl/ssl/s3_pkt.c1.1.1.10.2.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.3 src/crypto/openssl/ssl/s3_lib.c1.1.1.10.2.1 RELENG_6_4 src/UPDATING1.416.2.40.2.12 src/sys/conf/newvers.sh 1.69.2.18.2.14 src/crypto/openssl/ssl/s3_pkt.c 1.1.1.10.12.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.1.6.2 src/crypto/openssl/ssl/s3_lib.c 1.1.1.10.12.1 RELENG_6_3 src/UPDATING1.416.2.37.2.19 src/sys/conf/newvers.sh
bsd.security.see_other_uids affecting netstat?
Hi guys, Please forgive if this is a bit of a noob question I noticed that when the bsd.security.see_other_uids sysctl is set to 0, the netstat command gives no output for users (non-root). I can't find any mention of this in any documentation ... is this intentional? Cheers, Marc -- Our deepest fear is not that we are inadequate. Our deepest fear is that we are powerful beyond measure. It is our light, not our darkness, that most frightens us. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: bsd.security.see_other_uids affecting netstat?
2009/12/3 Marc Silver ma...@draenor.org: Hi guys, Please forgive if this is a bit of a noob question I noticed that when the bsd.security.see_other_uids sysctl is set to 0, the netstat command gives no output for users (non-root). No, it gives no access to sockets (switched to per-inpcb since 7) not owned by that user. See mac_seeotheruids(4): DESCRIPTION The mac_seeotheruids policy module, when enabled, denies users to see processes or sockets owned by other users. -- wbr, pluknet ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
FreeBSD Security Advisories ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-09:16.rtld Security Advisory The FreeBSD Project Topic: Improper environment sanitization in rtld(1) Category: core Module: rtld Announced: 2009-12-03 Affects:FreeBSD 7.0 and later. Corrected: 2009-12-01 02:59:22 UTC (RELENG_8, 8.0-STABLE) 2009-12-03 09:18:40 UTC (RELENG_8_0, 8.0-RELEASE-p1) 2009-12-01 03:00:16 UTC (RELENG_7, 7.2-STABLE) 2009-12-03 09:18:40 UTC (RELENG_7_2, 7.2-RELEASE-p5) 2009-12-03 09:18:40 UTC (RELENG_7_1, 7.1-RELEASE-p9) Sorry, this might seem a stupid question, but... In several places I read that FreeBSD 6.x is NOT affected; however, I heard some people discussing how to apply the patch to such systems. So, I'd like to know for sure: is 6.x affected? Is another patch on the way for it? bye Thanks av. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
ANNOUNCE: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-09:16.rtld Security Advisory The FreeBSD Project Topic: Improper environment sanitization in rtld(1) Category: core Module: rtld Announced: 2009-12-03 Affects:FreeBSD 7.0 and later. Corrected: 2009-12-01 02:59:22 UTC (RELENG_8, 8.0-STABLE) 2009-12-03 09:18:40 UTC (RELENG_8_0, 8.0-RELEASE-p1) 2009-12-01 03:00:16 UTC (RELENG_7, 7.2-STABLE) 2009-12-03 09:18:40 UTC (RELENG_7_2, 7.2-RELEASE-p5) 2009-12-03 09:18:40 UTC (RELENG_7_1, 7.1-RELEASE-p9) CVE Name: CVE-2009-4146, CVE-2009-4147 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.FreeBSD.org/. I. Background The run-time link-editor, rtld, links dynamic executable with their needed libraries at run-time. It also allows users to explicitly load libraries via various LD_ environmental variables. II. Problem Description When running setuid programs rtld will normally remove potentially dangerous environment variables. Due to recent changes in FreeBSD environment variable handling code, a corrupt environment may result in attempts to unset environment variables failing. III. Impact An unprivileged user who can execute programs on a system can gain the privileges of any setuid program which he can run. On most systems configurations, this will allow a local attacker to execute code as the root user. IV. Workaround No workaround is available, but systems without untrusted local users, where all the untrusted local users are jailed superusers, and/or where untrusted users cannot execute arbitrary code (e.g., due to use of read only and noexec mount options) are not affected. Note that untrusted local users include users with the ability to upload and execute web scripts (CGI, PHP, Python, Perl etc.), as they may be able to exploit this issue. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to the RELENG_8_0, RELENG_7_2, or RELENG_7_1 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 7.1, 7.2, and 8.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 7.x] # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld7.patch # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld7.patch.asc [FreeBSD 8.0] # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld.patch # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/libexec/rtld-elf # make obj make depend make make install NOTE: On the amd64 platform, the above procedure will not update the ld-elf32.so.1 (i386 compatibility) run-time link-editor (rtld). On amd64 systems where the i386 rtld are installed, the operating system should instead be recompiled as described in URL:http://www.FreeBSD.org/handbook/makeworld.html VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - - RELENG_7 src/libexec/rtld-elf/rtld.c 1.124.2.7 RELENG_7_2 src/UPDATING 1.507.2.23.2.8 src/sys/conf/newvers.sh 1.72.2.11.2.9 src/libexec/rtld-elf/rtld.c 1.124.2.4.2.2 RELENG_7_1 src/UPDATING1.507.2.13.2.12 src/sys/conf/newvers.sh 1.72.2.9.2.13 src/libexec/rtld-elf/rtld.c 1.124.2.3.2.2 RELENG_8 src/libexec/rtld-elf/rtld.c 1.139.2.4 RELENG_8_0 src/UPDATING 1.632.2.7.2.4 src/sys/conf/newvers.sh1.83.2.6.2.4 src/libexec/rtld-elf/rtld.c 1.139.2.2.2.2 - - Subversion: Branch/path Revision - - stable/7/ r199981 releng/7.2/ r200054 releng/7.1/
Re: Upcoming FreeBSD Security Advisory
On Dec 3, 2009, at 12:27 PM, Ivan Voras wrote: Borja Marcos wrote: On Dec 1, 2009, at 2:20 AM, FreeBSD Security Officer wrote: A short time ago a local root exploit was posted to the full-disclosure mailing list; as the name suggests, this allows a local user to execute arbitrary code as root. Dr. Strangelove, or How I learned to love the MAC subsystem. Hi, Could you point to, or write, some tutorial-like documentation on how you use the MAC for this particular purpose? I tried reading the mac* man pages in several instances before but can't seem to connect the theory described in there with how to apply it in a practical way. Could write, indeed. A problem with the MAC subsystem documentation is that it's too formal. But, my fault, I should have contributed long ago. Let me at least explain how I'm using it for fun and profit ;) Maybe I should write something for the wiki and enhance it over time. I have been using it for some time in a shared hosting server based on FreeBSD. It hosts many small websites, close to 1000 now, I think, so jail management was quite clumsy. The server is a shared hosting server based on Apache. Each user has an ftp account, chrooted to his home directory, of course. Users can upload PHP and CGI scripts, without restrictions in principle. My goals were: 1- Guarantee operating system integrity. Such a setup can suffer plenty of security compromises 2- Avoid escalation from one user to another. A compromised user account should not allow the user to read another user's files. 3- Keep it reasonably simple. Users only can manage their files by ftp. Although a next iteration could offer something more complete. 4- Allow CGI and PHP scripts written by customers to work without special modifications. If you give them a long list of requirements and restrictions, that will spell trouble. The goals were hard to meet. For instance, the Unix permissions model, which is very outdated for this kind of application, presents a serious problem. It's an elementary good practice to run a web server as an unprivileged user. So, html files (and, hence, php files) must be readable by all. But that means that a compromised user account, in case of escaping a chroot(), would be able to read other users' files. Integrity is hard to keep when you allow users to run php, cgi's... The solution adopted was to use the FreeBSD's MAC subsystem, exactly two elements: - The mac/biba policy, that assigns an integrity label to processes (subjects) and resources (objects) so that the following restrictions apply: A high integrity subject cannot read a lower integrity object. Think about a classical /tmp/.whatever_rc bobby trap left by an untrusted (lower integrity).. user. Your /usr/bin/whatever program, ran with your higher integrity level, would not be able to read the booby trap, so you would be safe. The problem is that it's awkward to do some administration tasks, but not impossible. A low integrity subject cannot modify a high integrity object. Our toothless root in my previous message, imagine that it comes from a compromised PHP script that was, of course, being executed with a low integrity label, cannot modify anything in the operating system, as anything is marked as high integrity by default. Again, it cannot leave bobby traps for other processes to execute. Not a crontab, an atjob, etc, because it lacks the necessary integrity level to do so. Integrity level cannot be increased once a process has been created with a low level, and as this applies as well to kmem et all, I think that a root exploit to overcome this is less likely to work than the typical privilege escalation exploit. There exists a special integrity label, biba/equal, which means do not check integrity. For instance, the system administrator can fork a shell with no checks when it's necessary to examine a user's directory (setpmac biba/equal bin/csh does the trick), and the backup program can be executed with a biba/equal integrity label. It will be able to read any files without restriction. Integrity labels can be applied to other resources such as network interfaces. Imagine you have a secondary network used for network based backups. If you label that network interface properly, a low integrity process spawned from a customer account will not be able to access that secondary network. - The mac/ugidfw policy, that allows you to setup a sort of ipfw-like restrictions. In our case, customers have uid numbers assigned belonging to a given range, say, 1 - 2, and the ugidfw policy is set up so that processes with a uid belonging to that interval cannot access resources belonging to a a different uid inside that interval. Processes with a uid belonging to this interval will have no interference from this module as long as the resource being accessed is owned by a non-customer uid. In that case only regular Unix
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Hi, = FreeBSD-SA-09:15.sslSecurity Advisory The FreeBSD Project [..] b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/secure/lib/libcrypto # make obj make depend make includes make make install Did you mean secure/lib/libssl rather than libcrypto? Regards, -- Niels. -- BitKat zo weten we nog steeds niet of de steganosaurus wel echt bestaan heeft ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
thus Jamie Landeg Jones spake: Sorry, this might seem a stupid question, but... In several places I read that FreeBSD 6.x is NOT affected; however, I heard some people discussing how to apply the patch to such systems. So, I'd like to know for sure: is 6.x affected? Is another patch on the way for it? bye Thanks av. snip So, what would be 'best of practice' to apply the patch to 6.3-RELEASE upwards -- is the FreeBSD-7 patch applicable or should one wait for an official announcement? Best, Timo The change that introduced the bug was made as follows: | Revision 1.124: download - view: text, markup, annotated - select for diffs | Thu May 17 18:00:27 2007 UTC (2 years, 6 months ago) by csjp | Branches: MAIN | CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 | Branch point for: RELENG_7 | Diff to: previous 1.123: preferred, colored | Changes since revision 1.123: +20 -10 lines | | In the event a process is tainted (setuid/setgid binaries), un-set any | potentially dangerous environment variables all together. It should be | noted that the run-time linker will not honnor these environment variables | if the process is tainted currently. However, once a child of the tainted | process calls setuid(2), it's status as being tainted (as defined by | issetugid(2)) will be removed. This could be problematic because | subsequent activations of the run-time linker could honnor these | dangerous variables. | | This is more of an anti foot-shot mechanism, there is nothing I am | aware of in base that does this, however there may be third party | utilities which do, and there is no real negative impact of clearing | these environment variables. | | Discussed on: secteam | Reviewed by: cperciva | PR: kern/109836 | MFC after: 2 weeks This was also ported MFC'd into 6.3 onwards: | Revision 1.106.2.7: download - view: text, markup, annotated - select for diffs | Sat Jul 14 19:04:00 2007 UTC (2 years, 4 months ago) by csjp | Branches: RELENG_6 | CVS tags: RELENG_6_4_BP, RELENG_6_3_BP, RELENG_6_3_0_RELEASE, RELENG_6_3 | Branch point for: RELENG_6_4 | Diff to: previous 1.106.2.6: preferred, colored; branchpoint 1.106: preferred, colored; next MAIN 1.107: preferred, colored | Changes since revision 1.106.2.6: +20 -10 lines | | MFC rtld.c revision 1.124 | | Unset potentially harmful environment variables. | | Discussed on: seacteam | PR: kern/109836 So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
Thu, Dec 03, 2009 at 02:09:36PM +0100, Niels Bakker wrote:
=
FreeBSD-SA-09:15.sslSecurity Advisory
The FreeBSD Project
[..]
b) Execute the following commands as root:
# cd /usr/src
# patch /path/to/patch
# cd /usr/src/secure/lib/libcrypto
# make obj make depend make includes make make install
Did you mean secure/lib/libssl rather than libcrypto?
Most probably, yes: both commits to 0.9.8k reference files
in libssl,
http://cvs.openssl.org/chngview?cn=18794
http://cvs.openssl.org/chngview?cn=18791
-
[/usr/src/secure/lib]$ grep -Er '(s3_srvr|s3_lib)' *
libssl/Makefile:s3_both.c s3_clnt.c s3_enc.c s3_lib.c s3_meth.c
s3_pkt.c \
libssl/Makefile:s3_srvr.c ssl_algs.c ssl_asn1.c ssl_cert.c ssl_ciph.c \
:: r...@void : 20:06:59 : /usr/src/secure/lib
$ grep -Er '(s3_srvr|s3_lib|ssl_err|s3_pkt|ssl3\.h)' *
libssl/Makefile:s3_both.c s3_clnt.c s3_enc.c s3_lib.c s3_meth.c
s3_pkt.c \
libssl/Makefile:s3_srvr.c ssl_algs.c ssl_asn1.c ssl_cert.c ssl_ciph.c \
libssl/Makefile:ssl_err.c ssl_err2.c ssl_lib.c ssl_rsa.c ssl_sess.c
ssl_stat.c \
libssl/Makefile:INCS= dtls1.h kssl.h ssl.h ssl2.h ssl23.h ssl3.h tls1.h
libssl/man/ssl.3:.IP \fBssl3.h\fR 4
libssl/man/ssl.3:.IX Item ssl3.h
-
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
Jamie Landeg Jones ha scritto:
So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't.
Thanks.
So, is a patch on the way for 6.[34] too?
I guess the sec team just wanted to get out what they had as soon as
possible and I agree with them and thanks them.
But I just need to plan... :-)
I don't know - are they still supported?
Anyway, I just made this patch. I don't have any 6.X machines to test it on,
but it should work on 6.3 and 6.4 (put it this way, if it doesn't work it
will fail to compile, rather than break your machine!):
Incidently, I am not part of the offical freebsd team.
cheers,
Jamie
--- rtld.c.orig 2007-07-14 20:04:00.0 +0100
+++ rtld.c 2009-12-03 17:29:58.0 +
@@ -349,11 +349,12 @@
* future processes to honor the potentially un-safe variables.
*/
if (!trust) {
-unsetenv(LD_ PRELOAD);
-unsetenv(LD_ LIBMAP);
-unsetenv(LD_ LIBRARY_PATH);
-unsetenv(LD_ LIBMAP_DISABLE);
-unsetenv(LD_ DEBUG);
+if (unsetenv(LD_ PRELOAD) || unsetenv(LD_ LIBMAP) ||
+ unsetenv(LD_ LIBRARY_PATH) || unsetenv(LD_ LIBMAP_DISABLE) ||
+ unsetenv(LD_ DEBUG)) {
+ _rtld_error(environment corrupt; aborting);
+ die();
+ }
}
ld_debug = getenv(LD_ DEBUG);
libmap_disable = getenv(LD_ LIBMAP_DISABLE) != NULL;
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
Hi-- On Dec 3, 2009, at 3:05 AM, Andrea Venturoli wrote: Sorry, this might seem a stupid question, but... In several places I read that FreeBSD 6.x is NOT affected; however, I heard some people discussing how to apply the patch to such systems. So, I'd like to know for sure: is 6.x affected? Is another patch on the way for it? Well, I've tested the exploit and FreeBSD 6.4-STABLE was not vulnerable. Starting with 7.x, rtld was significantly re-written from the prior version, and that re-write included the security vulnerability. The discussion you mention presumably involves checking out the patched version of rtld sources from 7.x or 8 and building+installing that under 6.x. Given that 6.x rtld is the older one with a longer history of security review and doesn't have the current known vulnerability, whereas the new version just got patched and might have other issues lurking, I am happy sticking with 6.x version on my 6.x boxes. Regards, -- -Chuck ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
The discussion you mention presumably involves checking out the patched version of rtld sources from 7.x or 8 and building+installing that under 6.x. Given that 6.x rtld is the older one with a longer history of security review and doesn't have the current known vulnerability, whereas the new version just got patched and might have other issues lurking, I am happy sticking with 6.x version on my 6.x boxes. A, I see. I was looking at the source of rtld.c to check when the change was made that allowed this vulnerability to exist, and that change was from 6.3 onwards. But it seems it's the changes to getenv/unsetenv from 7.0 onwards that cause this to be an exploitable issue. However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
Jamie Landeg Jones wrote: However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. The problem with that is, on 6.x, unsetenv() returns 'void', so there's no return value to check on. On 6.x (I've looked at 6.4-RELEASE-p7, it may be different in other versions), the unsetenv() uses __findenv() in a while loop to remove the given setting. The getenv() function also uses __findenv() to find the given environment setting. The issue described in the advisory simply doesn't exist in 6(.4-RELEASE-p7). -- Pieter ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
On 12/03/2009 08:01 PM, Pieter de Boer wrote: Jamie Landeg Jones wrote: However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. The problem with that is, on 6.x, unsetenv() returns 'void', so there's no return value to check on. On 6.x (I've looked at 6.4-RELEASE-p7, it may be different in other versions), the unsetenv() uses __findenv() in a while loop to remove the given setting. The getenv() function also uses __findenv() to find the given environment setting. The issue described in the advisory simply doesn't exist in 6(.4-RELEASE-p7). patch doesn't complain on the diff, but compiling gives me the following error on 6.4-STABLE (i386): # make depend rm -f .depend mkdep -f .depend -a-DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -DPIC /usr/src/libexec/rtld-elf/i386/rtld_start.S /usr/src/libexec/rtld-elf/i386/reloc.c /usr/src/libexec/rtld-elf/rtld.c /usr/src/libexec/rtld-elf/rtld_lock.c /usr/src/libexec/rtld-elf/map_object.c /usr/src/libexec/rtld-elf/malloc.c /usr/src/libexec/rtld-elf/xmalloc.c /usr/src/libexec/rtld-elf/debug.c /usr/src/libexec/rtld-elf/libmap.c echo ld-elf.so.1: /usr/lib/libc_pic.a .depend test# make cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/rtld_start.S cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/i386/reloc.c cc -O2 -fno-strict-aliasing -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -std=gnu99 -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rtld-elf/rtld.c /usr/src/libexec/rtld-elf/rtld.c: In function `_rtld': /usr/src/libexec/rtld-elf/rtld.c:352: error: void value not ignored as it ought to be /usr/src/libexec/rtld-elf/rtld.c:352: error: void value not ignored as it ought to be /usr/src/libexec/rtld-elf/rtld.c:353: error: void value not ignored as it ought to be /usr/src/libexec/rtld-elf/rtld.c:353: error: void value not ignored as it ought to be /usr/src/libexec/rtld-elf/rtld.c:354: error: void value not ignored as it ought to be *** Error code 1 Stop in /usr/src/libexec/rtld-elf. # Best, Timo ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
On 12/03/2009 08:01 PM, Pieter de Boer wrote: Jamie Landeg Jones wrote: However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. The problem with that is, on 6.x, unsetenv() returns 'void', so there's no return value to check on. As Pieter pointed out, unsetenv returns 'void', so checking for a return value (like that patch does) doesn't make sense. Sorry for wasting your time - the patch is not necessary (and won't even work) on 6.X systems, as you've discovered. Your system is safe from this attack, and any related ones. Jamie ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
On 12/03/2009 08:15 PM, Andrew Thompson wrote: On Thu, Dec 03, 2009 at 08:06:40PM +0100, Timo Schoeler wrote: On 12/03/2009 08:01 PM, Pieter de Boer wrote: Jamie Landeg Jones wrote: However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. The problem with that is, on 6.x, unsetenv() returns 'void', so there's no return value to check on. On 6.x (I've looked at 6.4-RELEASE-p7, it may be different in other versions), the unsetenv() uses __findenv() in a while loop to remove the given setting. The getenv() function also uses __findenv() to find the given environment setting. The issue described in the advisory simply doesn't exist in 6(.4-RELEASE-p7). patch doesn't complain on the diff, but compiling gives me the following error on 6.4-STABLE (i386): To quote the advisory Affects:FreeBSD 7.0 and later. i) there was not a big discussion on this list ii) humans are impeccable ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
On Thu, Dec 03, 2009 at 08:06:40PM +0100, Timo Schoeler wrote: On 12/03/2009 08:01 PM, Pieter de Boer wrote: Jamie Landeg Jones wrote: However, I'd still apply the patch in case some other way to exploit the non-checking of the unsetenv return status crops up elsewhere. It can't do any harm. The problem with that is, on 6.x, unsetenv() returns 'void', so there's no return value to check on. On 6.x (I've looked at 6.4-RELEASE-p7, it may be different in other versions), the unsetenv() uses __findenv() in a while loop to remove the given setting. The getenv() function also uses __findenv() to find the given environment setting. The issue described in the advisory simply doesn't exist in 6(.4-RELEASE-p7). patch doesn't complain on the diff, but compiling gives me the following error on 6.4-STABLE (i386): To quote the advisory Affects:FreeBSD 7.0 and later. Andrew ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
Any body can explain why no credit section for this advisory? On Thu, Dec 3, 2009 at 1:30 AM, FreeBSD Security Advisories security-advisor...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-09:16.rtld Security Advisory The FreeBSD Project Topic: Improper environment sanitization in rtld(1) Category: core Module: rtld Announced: 2009-12-03 Affects: FreeBSD 7.0 and later. Corrected: 2009-12-01 02:59:22 UTC (RELENG_8, 8.0-STABLE) 2009-12-03 09:18:40 UTC (RELENG_8_0, 8.0-RELEASE-p1) 2009-12-01 03:00:16 UTC (RELENG_7, 7.2-STABLE) 2009-12-03 09:18:40 UTC (RELENG_7_2, 7.2-RELEASE-p5) 2009-12-03 09:18:40 UTC (RELENG_7_1, 7.1-RELEASE-p9) CVE Name: CVE-2009-4146, CVE-2009-4147 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.FreeBSD.org/. I. Background The run-time link-editor, rtld, links dynamic executable with their needed libraries at run-time. It also allows users to explicitly load libraries via various LD_ environmental variables. II. Problem Description When running setuid programs rtld will normally remove potentially dangerous environment variables. Due to recent changes in FreeBSD environment variable handling code, a corrupt environment may result in attempts to unset environment variables failing. III. Impact An unprivileged user who can execute programs on a system can gain the privileges of any setuid program which he can run. On most systems configurations, this will allow a local attacker to execute code as the root user. IV. Workaround No workaround is available, but systems without untrusted local users, where all the untrusted local users are jailed superusers, and/or where untrusted users cannot execute arbitrary code (e.g., due to use of read only and noexec mount options) are not affected. Note that untrusted local users include users with the ability to upload and execute web scripts (CGI, PHP, Python, Perl etc.), as they may be able to exploit this issue. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 7-STABLE or 8-STABLE, or to the RELENG_8_0, RELENG_7_2, or RELENG_7_1 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 7.1, 7.2, and 8.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 7.x] # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld7.patch # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld7.patch.asc [FreeBSD 8.0] # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld.patch # fetch http://security.FreeBSD.org/patches/SA-09:16/rtld.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/libexec/rtld-elf # make obj make depend make make install NOTE: On the amd64 platform, the above procedure will not update the ld-elf32.so.1 (i386 compatibility) run-time link-editor (rtld). On amd64 systems where the i386 rtld are installed, the operating system should instead be recompiled as described in URL:http://www.FreeBSD.org/handbook/makeworld.html VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - - RELENG_7 src/libexec/rtld-elf/rtld.c 1.124.2.7 RELENG_7_2 src/UPDATING 1.507.2.23.2.8 src/sys/conf/newvers.sh 1.72.2.11.2.9 src/libexec/rtld-elf/rtld.c 1.124.2.4.2.2 RELENG_7_1 src/UPDATING 1.507.2.13.2.12 src/sys/conf/newvers.sh 1.72.2.9.2.13 src/libexec/rtld-elf/rtld.c 1.124.2.3.2.2 RELENG_8 src/libexec/rtld-elf/rtld.c 1.139.2.4 RELENG_8_0 src/UPDATING 1.632.2.7.2.4 src/sys/conf/newvers.sh 1.83.2.6.2.4 src/libexec/rtld-elf/rtld.c 1.139.2.2.2.2 - - Subversion: Branch/path Revision -
Re: FreeBSD Security Advisory FreeBSD-SA-09:16.rtld
Hello! The change that introduced the bug was made as follows: | Revision 1.124: download - view: text, markup, annotated - select for diffs | Thu May 17 18:00:27 2007 UTC (2 years, 6 months ago) by csjp | Branches: MAIN ... This was also ported MFC'd into 6.3 onwards: ... So, yes, FreeBSD 6.3-RELEASE upwards are affected - FreeBSD 6.2 isn't. Well, not exactly. This change introduces vulnerability _only_ if *env() implementation allows to create an environment, in which unsetenv(X) will fail but getenv(X) will still work. RELENG_6 luckily uses old, legacy, but _consistent_ *env() implementation which just uses the same variable search routine __findenv() both in getenv() and unsetenv(). So IMHO the advisory is correct, and there is no need to patch 6.*. Sincerely, Dmitry -- nic-hdl: LYNX-RIPE ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
FreeBSD Security Advisory FreeBSD-SA-09:15.ssl
On Thu, 3 Dec 2009 09:30:39 GMT, FreeBSD Security Advisories security-advisor...@freebsd.org said: NOTE WELL: This update causes OpenSSL to reject any attempt to renegotiate SSL / TLS session parameters. As a result, connections in which the other party attempts to renegotiate session parameters will break. In practice, however, session renegotiation is a rarely-used feature, so disabling this functionality is unlikely to cause problems for most systems. Actually, pretty much anyone who uses client certificates in an enterprise environment is likely to have a problem with this, which is why the IETF TLS working group is working on publishing a protocol fix. It looks like that RFC should be published, at Proposed Standard, in a few weeks, and most vendors look prepared to release implementations of the fix immediately thereafter (as soon as the relevant constants are assigned by IANA). -GAWollman ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
