Updating for the FreeBSD Security Advisory FreeBSD-SA-12:01.openssl
The following message appears when I do freebsd-update install The following files will be added as part of updating to 8.2-RELEASE-p7: /usr/src/lib/libc/gen/libc_dlopen.c The following files will be updated as part of updating to 8.2-RELEASE-p7: /boot/kernel/kernel /lib/libcrypto.so.6 /usr/bin/openssl /usr/include/openssl/ssl.h /usr/include/openssl/ssl3.h /usr/lib/libcrypto.a /usr/lib/libssl.a /usr/lib/libssl.so.6 /usr/lib32/libcrypto.a /usr/lib32/libcrypto.so.6 /usr/lib32/libcrypto_p.a /usr/lib32/libssl.a /usr/lib32/libssl.so.6 /usr/lib32/libssl_p.a /usr/src/sys/conf/newvers.sh /var/db/mergemaster.mtree WARNING: FreeBSD 8.2-RELEASE-p6 is approaching its End-of-Life date. It is strongly recommended that you upgrade to a newer release within the next 2 months. root@bljbsd01~:freebsd-update install Installing updates...install: ///usr/src/lib/libc/gen/libc_dlopen.c: No such file or directory done. Should I worry about the libc_dlopen.c, or is it ok? Thanks /Leslie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Follow up....Re: Updating for the FreeBSD Security Advisory FreeBSD-SA-12:01.openssl
2012-05-03 19:04, Leslie Jensen skrev: The following message appears when I do freebsd-update install The following files will be added as part of updating to 8.2-RELEASE-p7: /usr/src/lib/libc/gen/libc_dlopen.c The following files will be updated as part of updating to 8.2-RELEASE-p7: /boot/kernel/kernel /lib/libcrypto.so.6 /usr/bin/openssl /usr/include/openssl/ssl.h /usr/include/openssl/ssl3.h /usr/lib/libcrypto.a /usr/lib/libssl.a /usr/lib/libssl.so.6 /usr/lib32/libcrypto.a /usr/lib32/libcrypto.so.6 /usr/lib32/libcrypto_p.a /usr/lib32/libssl.a /usr/lib32/libssl.so.6 /usr/lib32/libssl_p.a /usr/src/sys/conf/newvers.sh /var/db/mergemaster.mtree WARNING: FreeBSD 8.2-RELEASE-p6 is approaching its End-of-Life date. It is strongly recommended that you upgrade to a newer release within the next 2 months. root@bljbsd01~:freebsd-update install Installing updates...install: ///usr/src/lib/libc/gen/libc_dlopen.c: No such file or directory done. Should I worry about the libc_dlopen.c, or is it ok? Thanks /Leslie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org After a reboot my system now has the following label FreeBSD 8.2-RELEASE-p3 #0 How come it downgrades the label from p6 to p3 when upgrading to p7. I'm aware that I can rebuild the kernel but I just wanted to know. /Leslie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Follow up....Re: Updating for the FreeBSD Security Advisory FreeBSD-SA-12:01.openssl
On Thu 2012-05-03 19:17:05 UTC+0200, Leslie Jensen (les...@eskk.nu) wrote: After a reboot my system now has the following label FreeBSD 8.2-RELEASE-p3 #0 How come it downgrades the label from p6 to p3 when upgrading to p7. This is a FAQ. There's a thread about it here: http://lists.freebsd.org/pipermail/freebsd-questions/2010-June/217031.html Short answer: The patch level (-p3) displayed by uname -r after a reboot will not change if freebsd-update has not touched the kernel. As far as I know there haven't been any patches to the 8.2-REL kernel since -p3. /usr/src/sys/conf/newvers.sh is always updated by freebsd-update when there is an update. (Although now that I think about it that might not be true if you don't have the kernel sources installed?) Not exactly intuitive. Several Linux distros have a file named /etc/issue that shows the distro name and version. Perhaps this or something similar could be provided in future FreeBSD releases and updated by freebsd-update. $ cat /etc/issue Ubuntu 12.04 LTS \n \l Regards Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Follow up....Re: Updating for the FreeBSD Security Advisory FreeBSD-SA-12:01.openssl
2012-05-03 20:35, andrew clarke skrev: On Thu 2012-05-03 19:17:05 UTC+0200, Leslie Jensen (les...@eskk.nu) wrote: After a reboot my system now has the following label FreeBSD 8.2-RELEASE-p3 #0 How come it downgrades the label from p6 to p3 when upgrading to p7. This is a FAQ. There's a thread about it here: http://lists.freebsd.org/pipermail/freebsd-questions/2010-June/217031.html Short answer: The patch level (-p3) displayed by uname -r after a reboot will not change if freebsd-update has not touched the kernel. As far as I know there haven't been any patches to the 8.2-REL kernel since -p3. /usr/src/sys/conf/newvers.sh is always updated by freebsd-update when there is an update. (Although now that I think about it that might not be true if you don't have the kernel sources installed?) Not exactly intuitive. Several Linux distros have a file named /etc/issue that shows the distro name and version. Perhaps this or something similar could be provided in future FreeBSD releases and updated by freebsd-update. $ cat /etc/issue Ubuntu 12.04 LTS \n \l Regards Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Thank you :-) I have read similar answers and was partly aware of this. But I was just curious to why. I'll accept it and let a kernel rebuild be a part of my updates. /Leslie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Follow up....Re: Updating for the FreeBSD Security Advisory FreeBSD-SA-12:01.openssl
On Thu 2012-05-03 20:48:17 UTC+0200, Leslie Jensen (les...@eskk.nu) wrote: Short answer: The patch level (-p3) displayed by uname -r after a reboot will not change if freebsd-update has not touched the kernel. ... I have read similar answers and was partly aware of this. But I was just curious to why. I'll accept it and let a kernel rebuild be a part of my updates. If you're running the GENERIC kernel then you're only creating extra work for yourself by rebuilding it for the sole purpose of having uname -r show the correct patchlevel... On the other hand if you're running a custom kernel then you only need to rebuild the kernel when freebsd-update touches the kernel sources. I don't recall the kernel was touched at all with the most recently -p7 patch (openssl), for example, so there's absolutely no need to rebuild it. Apologies if this was already obvious. Regards Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
In freebsd-questions Digest, Vol 408, Issue 10, Message: 5
On Sat, 31 Mar 2012 21:05:00 +0700 Erich Dollansky
erichfreebsdl...@ovitrap.com wrote:
On Saturday 31 March 2012 20:26:14 Julian H. Stacey wrote:
[..]
Da Rock wrote:
On 03/31/12 17:46, Julian H. Stacey wrote:
[..]
schu...@ime.usp.br wrote:
Hello,
I would like to raise a discussion about the security features
of FreeBSD as a whole and how they might be employed to actually
derive some meaningful guarantees.
We have a list specialy for freebsd-security@. Please use it.
I thought this to be sensible advice. Before seeing that I'd thought of
copying it to rwatson@ who I figured might take an interest due to his
involvement with Capsicum, acl(3) and such, but he certainly reads that
list anyway (and more than likely, not this one :)
Hang on, hold the phone: The security list (specifically) is for
security announcements. At least that what it said when I subscribed to
it...
Wrong.
Correct :)
For list of mail lists see:
http://lists.freebsd.org/mailman/listinfo
Specifically:
freebsd-secur...@freebsd.org
http://lists.freebsd.org/mailman/listinfo/freebsd-security
freebsd-security-notificati...@freebsd.org
http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
this sounds very confusing for people who have simple question:
'General system administrator questions of an FAQ nature are
off-topic for this list, but the creation and maintenance of a FAQ is
on-topic. Thus, the submission of questions (with answers) for
inclusion into the FAQ is welcome. Such question/answer sets should
be clearly marked as (at least FAQ submission) such in the subject.
'
schultz' post was nothing in the way of an FAQ issue, but a request for
discussion of a wide range of system security issues, far indeed from a
'simple question'. Had you posted the two paragraphs before the one you
quote above, this may have been a little clearer. To wit:
This is a technical discussion list covering FreeBSD security issues.
The intention is for the list to contain a high-signal, low-noise
discussion of issues affecting the security of FreeBSD.
Welcome topics include Cryptography (as it relates to FreeBSD), OS bugs
that affect security, and security design issues. Denial-of-service
(DoS) issues are less important than problems that allow an attacker to
achieve elevated privelige, but are still on-topic.
This sounds that 'schultz' would be wrong there.
Not at all Erich, quite the opposite in my view; as someone who's been
subscribed to freebsd-security@ for 12 or so years, I look forward to
seeing informed responses to some of schultz' issues. In any event,
{s,}he promptly took Julian's advice to post it there, where one aspect
has already attracted responses from des@ and pjd@
The best way to get a good sense of what issues are acceptible and/or
useful topics for which lists, without having to subscribe, is to browse
a list's archives for several months. Works for me. In this case try:
http://lists.freebsd.org/pipermail/freebsd-security/
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
On 04/02/12 17:48, Ian Smith wrote: In freebsd-questions Digest, Vol 408, Issue 10, Message: 5 On Sat, 31 Mar 2012 21:05:00 +0700 Erich Dollanskyerichfreebsdl...@ovitrap.com wrote: On Saturday 31 March 2012 20:26:14 Julian H. Stacey wrote: [..] Da Rock wrote: On 03/31/12 17:46, Julian H. Stacey wrote: [..] schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. I thought this to be sensible advice. Before seeing that I'd thought of copying it to rwatson@ who I figured might take an interest due to his involvement with Capsicum, acl(3) and such, but he certainly reads that list anyway (and more than likely, not this one :) Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... Wrong. Correct :) So thats turn left, right? Clear as mud now... :) For list of mail lists see: http://lists.freebsd.org/mailman/listinfo Specifically: freebsd-secur...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security freebsd-security-notificati...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications this sounds very confusing for people who have simple question: 'General system administrator questions of an FAQ nature are off-topic for this list, but the creation and maintenance of a FAQ is on-topic. Thus, the submission of questions (with answers) for inclusion into the FAQ is welcome. Such question/answer sets should be clearly marked as (at least FAQ submission) such in the subject. ' schultz' post was nothing in the way of an FAQ issue, but a request for discussion of a wide range of system security issues, far indeed from a 'simple question'. Had you posted the two paragraphs before the one you quote above, this may have been a little clearer. To wit: This is a technical discussion list covering FreeBSD security issues. The intention is for the list to contain a high-signal, low-noise discussion of issues affecting the security of FreeBSD. I think that has clarified things sufficiently now. Looks like I should subscribe to that list too. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
Hello. 2012/03/30 22:44:16 -0300 schu...@ime.usp.br = To freebsd-questions@freebsd.org : P.S.: If you want to attain desktop security, matters get even more complicated. If anyone is interested, I can discuss what I did there (basically virtual X servers and building ports as regular users). Sure I am interested. I myself try to run Xorg server in a chroot and its clients from a different jail(s) via tcp on lo0. Trouble still is I can't get my VT ttyvXs because of that strange 'console ownership' stuff. Also, thanks for Capsicum, it sure is useful. Who is that? -- Peter Vereshagin pe...@vereshagin.org (http://vereshagin.org) pgp: A0E26627 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
On 01/04/2012 09:47, Peter Vereshagin wrote: Also, thanks for Capsicum, it sure is useful. Who is that? Robert Watson, Jonathan Anderson and Ben Laurie are the principle 'who' behind Capsicum. Now, if you'ld asked 'What is that?' I'd've pointed you towards https://www.cl.cam.ac.uk/research/security/capsicum/ It's a lightweight OS capability and sandbox framework, or in other words a way of enforcing restrictions on what objects -- particularly those built from foreign data eg. javascript in web pages -- can modify or access on your local system. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: FreeBSD Security in Multiuser Environments
Hi, Reference: From: schu...@ime.usp.br Date: Fri, 30 Mar 2012 22:44:16 -0300 Message-id: 20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
On 03/31/12 17:46, Julian H. Stacey wrote: Hi, Reference: From: schu...@ime.usp.br Date: Fri, 30 Mar 2012 22:44:16 -0300 Message-id: 20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
Hi, Reference: From: Da Rock freebsd-questi...@herveybayaustralia.com.au Date: Sat, 31 Mar 2012 21:25:37 +1000 Message-id: 4f76e9b1.5040...@herveybayaustralia.com.au Da Rock wrote: On 03/31/12 17:46, Julian H. Stacey wrote: Hi, Reference: From: schu...@ime.usp.br Date: Fri, 30 Mar 2012 22:44:16 -0300 Message-id:20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... Wrong. For list of mail lists see: http://lists.freebsd.org/mailman/listinfo Specifically: freebsd-secur...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security freebsd-security-notificati...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security in Multiuser Environments
Hi, On Saturday 31 March 2012 20:26:14 Julian H. Stacey wrote: Hi, Reference: From: Da Rock freebsd-questi...@herveybayaustralia.com.au Date: Sat, 31 Mar 2012 21:25:37 +1000 Message-id: 4f76e9b1.5040...@herveybayaustralia.com.au Da Rock wrote: On 03/31/12 17:46, Julian H. Stacey wrote: Hi, Reference: From:schu...@ime.usp.br Date:Fri, 30 Mar 2012 22:44:16 -0300 Message-id: 20120330224416.13643xk4rsfd2...@webmail.ime.usp.br schu...@ime.usp.br wrote: Hello, I would like to raise a discussion about the security features of FreeBSD as a whole and how they might be employed to actually derive some meaningful guarantees. We have a list specialy for freebsd-security@. Please use it. Hang on, hold the phone: The security list (specifically) is for security announcements. At least that what it said when I subscribed to it... Wrong. For list of mail lists see: http://lists.freebsd.org/mailman/listinfo Specifically: freebsd-secur...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security freebsd-security-notificati...@freebsd.org http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications this sounds very confusing for people who have simple question: 'General system administrator questions of an FAQ nature are off-topic for this list, but the creation and maintenance of a FAQ is on-topic. Thus, the submission of questions (with answers) for inclusion into the FAQ is welcome. Such question/answer sets should be clearly marked as (at least FAQ submission) such in the subject. ' This sounds that 'schultz' would be wrong there. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD Security in Multiuser Environments
Hello,
I would like to raise a discussion about the security features
of FreeBSD as a whole and how they might be employed to actually
derive some meaningful guarantees.
I have found myself administering a system with many potentially
untrusted users. Furthermore, some users do not trust some of the
programs they run and are thus allowed to ask for some slave
accounts. A slave account is a user account accessible only to
root and the master user. This can lead to a hierachy of authority.
Also, each account has potentially confidential data that may be
accessed only by the account itself and its ancestor accounts. This
includes when a user is logged on and what the user is running.
Finally, the system must always be up so no user untrusted by root
may trash it.
This is a pretty harsh set of restrictions and is almost unmanageable.
However, I have taken three steps to ensure security: base system
hardening, using sudo for privilege granting and using rctl(8) for
resource accounting and control. Gathering enough information in these
three areas has been an ongoing task for almost half a year, and I
would like to discuss some problems of my approach.
In terms of system hardening, I have:
* Encrypted the whole (except /boot) system with geli(8)
(HMAC/SHA256 and AES-XTS). It is not as nice and much slower
than proper filesystem-level checksumming but it is what
FreeBSD provides (ZFS is too unstable).
* Disabled useless and potentially dangerous services: cron, devd
and sendmail.
* Removed every setuid bit. The system works even then.
* Hardened /dev: every non necessary device has had the 0007 bits
stripped. Optional groups were created (e.g. audio, mixer and mic
for devices /dev/{mixer,dsp,audio}*).
* Hardened the sysctls:
- security.bsd.see_other_uids=0: Users can only see own processes.
- security.bsd.unprivileged_proc_debug=0
- security.bsd.unprivileged_read_msgbuf=0: The log is considered
sensitive information.
- security.bsd.hardlink_check_uid=1: Avoid hardlinks to old SUID
binaries.
- kern.log_console_output=0
- kern.coredump=0
- vm.overcommit=1: This avoids retarded Linux-like behaviour on
OOM conditions.
* Changed permissions on /root to 0700: root deserves privacy.
* A boot script changes some permissions:
- /var/log to 0750: the logs are considered sensitive information.
- /var/run/dmesg.boot to 0640: this is also sensitive information.
* Added a group sudoers and made sudo setuid only to users in
sudoers: would have avoided trouble with recent sudo exploit if
only trusted users have slaves.
As for using sudo to grant privilege, for each master-slave
relationship between users u and v, I have added a line like
u ALL = (v) NOPASSWD: ALL to /etc/sudoers. Then the user u is
supposed to become v by issuing sudo -i -u v and to execute a
command as v by issuing sudo -i -u v
It is worth noticing that sudo closes all file descriptors greater than
or equal to 3. It is important not to let your pseudo-terminal leak
through file descriptors 0, 1 and 2 if you have a shell connected to
it. Also, the -i is mandatory because otherwise a file descriptor
open at directory . is leaked via the cwd file descriptor. I
believe this is enough, but since this is not properly documented, I
am not sure.
As for resource limiting via rctl(8), for each user u root does not
trust, I have added three rules:
* user:u:vmemoryuse:deny=MEM
* user:u:maxproc:deny=PROCS
* user:u:pseudoterminals:deny=0
Here MEM and PROCS are limits on total virtual memory usage and
total occupied entries in the process table for process u,
respectively. Furthermore, I never give access to pseudo-terminals to
untrusted users because all sessions are started from ssh or ptys of
trusted users. Also, ptys must be available otherwise trusted users can
not work on the machine. Finally, I have noticed rctl -u user:u
reports a single pty open for user u no matter how many open ptys u has
(except of course if u has no open pty, in which case 0 is reported).
One naively would expect these restrictions to be enough to prevent
abuse (trashing or DoS) as long as the sum of the MEM values (rounded
up to page size) is less than or equal to the total physical memory
plus swap space less the system (and trusted users') memory usage and
the sum of the PROC values is less than the process table size minus
the number of trusted processes. I sincerely do not know if this is the
case.
However, using vmemoryuse as a limit is overkill: it counts the total
mapped pages, not the total anonymous pages, which are the ones that
actually take resources. Of course, this assumes the memory management
data structures (including the page table) are accounted as anonymous
memory of the corresponding process, since it is easy (especially on
amd64), to map pages sparsely to greatly increase the size of the
page table. However, I do not know if this assumption holds on
Fw: Merry Christmas from the FreeBSD Security Team
_ From: FreeBSD Security Officer [mailto:cperc...@freebsd.org] To: freebsd-secur...@freebsd.org Sent: Fri, 23 Dec 2011 16:41:20 +0100 Subject: Merry Christmas from the FreeBSD Security Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories. The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories. Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time. While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk70oR8ACgkQFdaIBMps37IHEwCeNT8dws04qyJ8yuOz7g2xd9Xs IsoAn0QfaSE6i90zFBuk1k0isvrDMYO3 =p94J -END PGP SIGNATURE- merry Christmas Disclaimer: http://www.ose.nl/email ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [Spam] Fw: Merry Christmas from the FreeBSD Security Team
--As of December 23, 2011 5:45:42 PM +0100, Bas Smeelen is alleged to have said: While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. --As for the rest, it is mine. I appreciate the hard work, though I could wish it were better timed. ;) However, the above does worry me a bit: Is that same library change likely to affect ports? Any way to tell which, if so? (Or should I just start reinstalling everything...) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD Security Advisory FreeBSD-SA-09:12.bind
Trying to apply this to a 6.4 box with no manpages install. Install fails because the man3 directory doesn't exist. is this expected? Adding the src.conf knob of WITHOUT_MAN=1 still prevents the updated libraries to install. I'm just following the directions on the advisory and doesn't install cleanly. I'm not running named/bind on the box, so there is no immediate pressure, but I'd still like to apply the fix. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Freebsd-update and Freebsd Security Advisory
Dear all, I hope you can help me understand various ways to patch FBSD system. Today I got a FreeBSD Security Advisory which advised me to apply libarchive.patch. Which I did. All went file. But then I issued freebsd-update fetch and the system fetched two metapatches or so. I went ahead and installed them (it took less than a second) so don't know if they were really installed. I guess these were the same patches for libarchive. I think I am doing a bad thing mixing these two patching systems. What should I do now? Should I go back and revert some changes? FreeBSD szalbot.homedns.org 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #3: Wed Jul 4 08:21:48 CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SZALBOT i386 When I issue freebsd-update fetch, I get Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 6.2-RELEASE-p6. Am I safe to continue patching the system either way or should I keep only to one? Many thanks for your advice! Warm regards, Zbigniew Szalbot ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd-update and Freebsd Security Advisory
I think I am doing a bad thing mixing these two patching systems. What should I do now? Should I go back and revert some changes? No it seems you don't need to revert anything. But you should avoid mixing in the future. No updates needed to update system to 6.2-RELEASE-p6. That is already the last update, so there is nothing more needed, freebsd-update detected that. You were 6.2-RELEASE-p5 which was the last before the libarchive, patched libarchive, so you are p6 which is OK. Am I safe to continue patching the system either way or should I keep only to one? I don't know how freebsd-update works, so I cannot tell you what is safe doing, except do not mix. I know that for system patch, I will either apply the patch manually and rebuild the kernel, or update the full system and rebuild everything, depending on my mood and on the possible impact on the system. I just try to keep trak of what I have done. Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [FreeBSD-Announce] FreeBSD Security AdvisoryFreeBSD-SA-06:23.openssl [REVISED]
HI, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of FreeBSD Security Advisories Sent: Friday, September 29, 2006 4:00 PM To: FreeBSD Security Advisories Subject: [FreeBSD-Announce] FreeBSD Security AdvisoryFreeBSD-SA-06:23.openssl [REVISED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == === FreeBSD-SA-06:23.openssl Security Advisory The FreeBSD Project Topic: Multiple problems in crypto(3) ..snip.. 1) Upgrade your vulnerable system to 4-STABLE, 5-STABLE, or 6-STABLE, or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, RELENG_5_3, or RELENG_4_11 security branch dated after the correction date. 2) To patch your present system: The following patch has been verified to apply to FreeBSD 4.11, 5.3, 5.4, 5.5, 6.0, and 6.1 systems. a) Download the patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-06:23/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-06:23/openssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch c) Recompile the operating system as described in URL: http://www.freebsd.org/handbook/makeworld.html and reboot the system. I have done these 3 steps already: # make buildworld # make buildkernel # make installkernel Do i need to do these steps too? # mergemaster -p # make installworld # mergemaster I have FreeBSD 6.1 Release Thanks for your help Pascal Bleyler ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD Security AdvisoryFreeBSD-SA-06:23.openssl [REVISED]
Pascal Bleyler wrote: == === FreeBSD-SA-06:23.openssl Security Advisory [snip] I have done these 3 steps already: # make buildworld # make buildkernel # make installkernel Do i need to do these steps too? # mergemaster -p # make installworld # mergemaster I have FreeBSD 6.1 Release Yes, you absolutely do need to do those steps. The OpenSSL vulnerabilities were in various shared libraries installed as part of the base system. Just replacing the kernel won't do a thing to fix those shlibs. 'make installworld' will, and you need to run mergemaster to keep your /etc files in sync with the rest of the world. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl
Can anyone define exceptionally large as noted in this statement?: NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by prohibiting the use of exceptionally large public keys. It is believed that no existing applications legitimately use such key lengths as would be affected by this change. It would be nice if exceptionally large were replaced with keys in excess of x bits in size or something. I don't expect that this will affect me, but ambiguous statements like that make me uncomfortable. Begin forwarded message: Date: Thu, 28 Sep 2006 13:13:53 GMT From: FreeBSD Security Advisories [EMAIL PROTECTED] To: FreeBSD Security Advisories [EMAIL PROTECTED] Cc: Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-06:23.opensslSecurity Advisory The FreeBSD Project Topic: Multiple problems in crypto(3) Category: contrib Module: openssl Announced: 2006-09-28 Credits:Dr S N Henson, Tavis Ormandy, Will Drewry Affects:All FreeBSD releases. Corrected: 2006-09-28 13:02:37 UTC (RELENG_6, 6.1-PRERELEASE) 2006-09-28 13:03:14 UTC (RELENG_6_1, 6.1-RELEASE-p8) 2006-09-28 13:03:41 UTC (RELENG_6_0, 6.0-RELEASE-p13) 2006-09-28 13:03:57 UTC (RELENG_5, 5.5-STABLE) 2006-09-28 13:04:16 UTC (RELENG_5_5, 5.5-RELEASE-p6) 2006-09-28 13:04:47 UTC (RELENG_5_4, 5.4-RELEASE-p20) 2006-09-28 13:05:08 UTC (RELENG_5_3, 5.3-RELEASE-p35) 2006-09-28 13:05:59 UTC (RELENG_4, 4.11-STABLE) 2006-09-28 13:06:23 UTC (RELENG_4_11, 4.11-RELEASE-p23) CVE Name: CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4343 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 FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description Several problems have been found in OpenSSL: 1. During the parsing of certain invalid ASN1 structures an error condition is mishandled, possibly resulting in an infinite loop. [CVE-2006-2937] 2. A buffer overflow exists in the SSL_get_shared_ciphers function. [CVE-2006-3738] 3. A NULL pointer may be dereferenced in the SSL version 2 client code. [CVE-2006-4343] In addition, many applications using OpenSSL do not perform any validation of the lengths of public keys being used. [CVE-2006-2940] III. Impact Servers which parse ASN1 data from untrusted sources may be vulnerable to a denial of service attack. [CVE-2006-2937] An attacker accessing a server which uses SSL version 2 may be able to execute arbitrary code with the privileges of that server. [CVE-2006-3738] A malicious SSL server can cause clients connecting using SSL version 2 to crash. [CVE-2006-4343] Applications which perform public key operations using untrusted keys may be vulnerable to a denial of service attack. [CVE-2006-2940] IV. Workaround No workaround is available, but not all of the vulnerabilities mentioned affect all applications. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE, 5-STABLE, or 6-STABLE, or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, RELENG_5_3, or RELENG_4_11 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.11, 5.3, 5.4, 5.5, 6.0, and 6.1 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-06:23/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-06:23/openssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch c) Recompile the operating system as described in URL: http://www.freebsd.org/handbook/makeworld.html and reboot the system. NOTE: Any third-party applications, including those installed from the FreeBSD ports collection, which are statically linked to libcrypto(3) should be recompiled in order to use the corrected code. NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by prohibiting the use of exceptionally large public keys. It is believed that no existing applications legitimately use such key lengths as would be affected by this change. VI
Re: Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl
Bill Moran wrote: Can anyone define exceptionally large as noted in this statement?: NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by prohibiting the use of exceptionally large public keys. It is believed that no existing applications legitimately use such key lengths as would be affected by this change. It would be nice if exceptionally large were replaced with keys in excess of x bits in size or something. I don't expect that this will affect me, but ambiguous statements like that make me uncomfortable. DH and DSA are limited to 1 bits. RSA is limited to 16400 or 4112 bits depending upon whether the public exponent is less or more than 72 bits. I wouldn't have allowed this change into the security branches if I was not very very confident that no applications would be affected by this. Colin Percival ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl
In response to Colin Percival [EMAIL PROTECTED]: Bill Moran wrote: Can anyone define exceptionally large as noted in this statement?: NOTE ALSO: The above patch reduces the functionality of libcrypto(3) by prohibiting the use of exceptionally large public keys. It is believed that no existing applications legitimately use such key lengths as would be affected by this change. It would be nice if exceptionally large were replaced with keys in excess of x bits in size or something. I don't expect that this will affect me, but ambiguous statements like that make me uncomfortable. DH and DSA are limited to 1 bits. RSA is limited to 16400 or 4112 bits depending upon whether the public exponent is less or more than 72 bits. I wouldn't have allowed this change into the security branches if I was not very very confident that no applications would be affected by this. Colin Percival I'm not questioning your ability to make these decisions, Colin. Far, far from it. I'm the type that is made uncomfortable by any statement that reads _anything_ like don't worry, we've taken care of it. Take that email as two separate statements: 1) I'm curious as to exactly how big exceptionally large is. 2) I think this security advisory could be improved by including the answer to #1. Thanks for the quick response, and all the work you do. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD Security Survey
Colin, Just a couple problems with the survey: Question #6 needs a Sometimes as it is not going to be a yes or no question for many people. Your also ignoring the fact that many security holes are a lot easier to ignore and just block off the affected service. For example we run an older RADIUS daemon that has the hole in it that CERT documented a few years ago. But we restrict incoming radius queries to this server to the NAS only. When the FreeBSD telnetd problem came out a few years back I didn't bother patching systems, I just disabled telnetd and waited until it was time to replace the server with a new version of FreeBSD. The thing is, though, that when your dealing with a production server you really have to understand what is involved to apply a patch. You don't just go to a production system that a lot of people are using and run some automated patch-me program that fucks around with a bunch of files on that server under the hood. You have to apply the patch to a test system, by hand, to know exactly what it's changing, then run your test suite on the test system to make sure the production system isn't going to tank when you touch it, then schedule a time to touch the production system and patch it, and make sure you have plenty of time in your schedule available post-patch just in case something reacts wrong. And, when the FBSD system is a server you have built under spec for a customer, it's a whole different ballgame because before you spend a minute of time on it, you have to go to the customer and tell them a security patch came out for their server and they got to pay you a couple hundred bucks to install it on their server you built for them. Your not going to work for free. And the customer may take the attitude that they are planning on replacing the server in 6 months anyway, and at that time you can just use a new version of FBSD that doesen't have the hole, and they are just going to take their chances until then. In that situation even if patching their server was merely a matter of spending 2 minutes logging into it and running an updater, you still wouldn't do it and you know why? Because the second you start doing work for that customer for free, they are going to expect it. It's better from a business perspective for you to warn them their server is open and they have to pay you to patch it, have them decline for the moment and leave it unpatched because they are going to gamble for another 6 months that it won't be attacked, and then have a cracker bust it up so you can tell them I told you we needed to patch that and you decided to cheap out, look what you get (of course you say it in a more diplomatic way) Your survey responses lack any responses that indicate that leaving the system unpatched may be deliberately done, for monetary reasons, your responses in the survey assume that all system admins that understand the security implications of leaving a system wide open are going to always patch them, and only ignorant/newbie system admins are going to run an unpatched system. And the other problem too is that there's still a lot of hardware out there that runs FreeBSD 4.11 much better than 5.X and later. I have a number of Compaq dual-PPro deskpros for example that work fine under 4.11 but run slow as molassas under newer versions of FreeBSD. send-pr reports are pointless here since many people have already complained about such behavior with a lot of different gear, and it appears all the FBSD developers today are building on nice new gigahertz hardware not old stuff, and have the attitude to just scrap the old hardware, and buy new, it's cheap enough. You need to add another question like: X) why are you running an obsolete version of FreeBSD: ) hardware I have doesen't work well with newer versions of FBSD But, I realize that very likely you won't add this because it's not something the FBSD development team wants to hear. (ie: spend more time optimizing and working through the PR database and less time coming out with new gee-whiz FBSD versions and trying to get people to upgrade) Good luck with it, but understand also that the same issues apply to patching Windows systems. When we install a Windows server, we never turn on auto-updates, we only do this for desktops. And before applying a MS patch to a Windows server it has to go through the same rigamarole of testing and such that a patch to a FBSD server would. Too many times in the past, patches have broken application software. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Colin Percival Sent: Sunday, May 21, 2006 10:34 PM To: FreeBSD Questions Subject: FreeBSD Security Survey Dear FreeBSD users and system administrators, While the FreeBSD Security Team has traditionally been very good at investigating and responding to security issues in FreeBSD, this only solves half of the security problem: Unless users
RE: FreeBSD Security Survey
[mailto:[EMAIL PROTECTED] On Behalf Of Ted Mittelstaedt Sent: Sunday, May 21, 2006 11:20 PM To: Colin Percival; FreeBSD Questions Subject: RE: FreeBSD Security Survey Colin, Just a couple problems with the survey: Question #6 needs a Sometimes as it is not going to be a yes or no question for many people. Your also ignoring the fact that many security holes are a lot easier to ignore and just block off the affected service. For example we run an older RADIUS daemon that has the hole in it that CERT documented a few years ago. But we restrict incoming radius queries to this server to the NAS only. When the FreeBSD telnetd problem came out a few years back I didn't bother patching systems, I just disabled telnetd and waited until it was time to replace the server with a new version of FreeBSD. The thing is, though, that when your dealing with a production server you really have to understand what is involved to apply a patch. You don't just go to a production system that a lot of people are using and run some automated patch-me program that fucks around with a bunch of files on that server under the hood. You have to apply the patch to a test system, by hand, to know exactly what it's changing, then run your test suite on the test system to make sure the production system isn't going to tank when you touch it, then schedule a time to touch the production system and patch it, and make sure you have plenty of time in your schedule available post-patch just in case something reacts wrong. And, when the FBSD system is a server you have built under spec for a customer, it's a whole different ballgame because before you spend a minute of time on it, you have to go to the customer and tell them a security patch came out for their server and they got to pay you a couple hundred bucks to install it on their server you built for them. Your not going to work for free. And the customer may take the attitude that they are planning on replacing the server in 6 months anyway, and at that time you can just use a new version of FBSD that doesen't have the hole, and they are just going to take their chances until then. In that situation even if patching their server was merely a matter of spending 2 minutes logging into it and running an updater, you still wouldn't do it and you know why? Because the second you start doing work for that customer for free, they are going to expect it. It's better from a business perspective for you to warn them their server is open and they have to pay you to patch it, have them decline for the moment and leave it unpatched because they are going to gamble for another 6 months that it won't be attacked, and then have a cracker bust it up so you can tell them I told you we needed to patch that and you decided to cheap out, look what you get (of course you say it in a more diplomatic way) Your survey responses lack any responses that indicate that leaving the system unpatched may be deliberately done, for monetary reasons, your responses in the survey assume that all system admins that understand the security implications of leaving a system wide open are going to always patch them, and only ignorant/newbie system admins are going to run an unpatched system. And the other problem too is that there's still a lot of hardware out there that runs FreeBSD 4.11 much better than 5.X and later. I have a number of Compaq dual-PPro deskpros for example that work fine under 4.11 but run slow as molassas under newer versions of FreeBSD. send-pr reports are pointless here since many people have already complained about such behavior with a lot of different gear, and it appears all the FBSD developers today are building on nice new gigahertz hardware not old stuff, and have the attitude to just scrap the old hardware, and buy new, it's cheap enough. You need to add another question like: X) why are you running an obsolete version of FreeBSD: ) hardware I have doesen't work well with newer versions of FBSD But, I realize that very likely you won't add this because it's not something the FBSD development team wants to hear. (ie: spend more time optimizing and working through the PR database and less time coming out with new gee-whiz FBSD versions and trying to get people to upgrade) Good luck with it, but understand also that the same issues apply to patching Windows systems. When we install a Windows server, we never turn on auto-updates, we only do this for desktops. And before applying a MS patch to a Windows server it has to go through the same rigamarole of testing and such that a patch to a FBSD server would. Too many times in the past, patches have broken application software. Ted Colin, I had the same problem with #6 and also with #12. #9, which offered a time-line, was better. All needed an other field. In my case, the servers aren't
Re: FreeBSD Security Survey
I'd have to agree with most of Ted and Gayn's points. Also, it's hard to answer many of the questions when they are different for different servers. Unless there is a serious bug in something like SSH, then a paying client with a seriously firewalled server and no malicious users might get upgraded every four months. My own server might get upgraded weekly when I'm not too busy, or not for four months when I am. But a security bug with a network service would get much more immediate attention. If I still administered machines in an academic environment, my answers would be quite different, but the risk analysis that led to the different answers would (theoretically) be the same. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Security Survey
Dear FreeBSD users and system administrators, While the FreeBSD Security Team has traditionally been very good at investigating and responding to security issues in FreeBSD, this only solves half of the security problem: Unless users and administrators of FreeBSD systems apply the security patches provided, the advisories issued accomplish little beyond alerting potential attackers to the presence of vulnerabilities. The Security Team has been concerned for some time by anecdotal reports concerning the number of FreeBSD systems which are not being promptly updated or are running FreeBSD releases which have passed their End of Life dates and are no longer supported. In order to better understand which FreeBSD versions are in use, how people are (or aren't) keeping them updated, and why it seems so many systems are not being updated, I have put together a short survey of 12 questions. The information gathered will inform the work done by the Security Team, as well as my own personal work on FreeBSD this summer. If you administrate system(s) running FreeBSD (in the broad sense of are responsible for keeping system(s) secure and up to date), please visit http://people.freebsd.org/~cperciva/survey.html and complete the survey below before May 31st, 2006. Thanks, Colin Percival FreeBSD Security Officer ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:07.pf
III. Impact By sending carefully crafted sequence of IP packet fragments, a remote attacker can cause a system running pf with a ruleset containing a 'scrub fragment crop' or 'scrub fragment drop-ovl' rule to crash. IV. Workaround Do not use 'scrub fragment crop' or 'scrub fragment drop-ovl' rules on systems running pf. In most cases, such rules can be replaced by 'scrub fragment reassemble' rules; see the pf.conf(5) manual page for All: Just to clarify on the syntax, since it's not actually mentioned in pf.conf(5): Per the PF FAQ, a rule: scrub in all or scrub all Implies scrub in all fragment reassemble as a default argument/flags to scrub when not are specified, and none of the other scrubbing options (no-df, random-id, etc.). This per observation of pfctl -s all: $ sudo grep -i scrub /etc/pf.conf scrub in all $ sudo pfctl -s all | grep -i scrub scrub in all fragment reassemble Correct? To the credit of the FAQ Author, it does state This is the default behavior when no fragment option is specified. ... but that still begs the question: What are the default scrubbing options, other than fragment reassembly, when none are specified? Might be useful to mention these things in the FAQ and the advisory. TIA, ~lava more details. Systems which do not use pf, or use pf but do not use the aforementioned rules, are not affected by this issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
open source freebsd security appliance project
Hi, all I have tried to build a security applicance based on FreeBSD 4.7 since 2001. Which contains: central syslog server (syslogd) ntp sevice (ntpd) dhcp server (dhcpd) dns (bind) IPSec (ipsec-tools) PPTP (mpd) firewall (ipfilter) traffic shape (ALTQ) IDS (snort) Utilization monitor (MRTG) Web console including 1. report system for firewall, ids, system 2. configuration interface for some sub-system (not actually working yet) Recently, I upgraded this appliance to FreeBSD 6.0. Now I got: * a new list of required package * a custom kernel configuration file for 6.0 * collection of my custom packages (mostly perl based) Old web pages for this appliance avaliable here: http://isolution.dyndns.biz/en/si/sc/feature.html Some code are broken after upgrade to 6.0. A document to put them all togather is not completed yet. I plan to start a open source project base on current resource and the goal is to build a small and compact FreeBSD security appliance, most importantly cost effective. The first step is starting a close test before release it to public and discuss how to proceed. If you are FreeBSD power user and interested, you are welcome to contact me and receive a copy of current work. Any suggestions are always welcome. Vincent Chen ___ 最新版 Yahoo!奇摩即時通訊 7.0，免費網路電話任你打！ http://messenger.yahoo.com.tw/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open source freebsd security appliance project
The question of the day is: why are you porting it to 6.0? Have you proven that its better? There are many commercial appliances that are sticking with 4.x because its more suitable for that kind of application. The issue with an open-source type of appliance is capacity; The kind of people that really need such an appliance AND have the talent in house to benefit from it usually need more than ALTQ and IPFIREWALL can deliver. You'll only diminish that by going to 6.0, while also introducing the one thing that will keep anyone from using any product: instability. After all, a slow stable appliance is of some use to some people; while even a really fast unstable appliance is of use to no-one at all. DT --- Vincent Chen [EMAIL PROTECTED] wrote: Hi, all I have tried to build a security applicance based on FreeBSD 4.7 since 2001. Which contains: central syslog server (syslogd) ntp sevice (ntpd) dhcp server (dhcpd) dns (bind) IPSec (ipsec-tools) PPTP (mpd) firewall (ipfilter) traffic shape (ALTQ) IDS (snort) Utilization monitor (MRTG) Web console including 1. report system for firewall, ids, system 2. configuration interface for some sub-system (not actually working yet) Recently, I upgraded this appliance to FreeBSD 6.0. Now I got: * a new list of required package * a custom kernel configuration file for 6.0 * collection of my custom packages (mostly perl based) Old web pages for this appliance avaliable here: http://isolution.dyndns.biz/en/si/sc/feature.html Some code are broken after upgrade to 6.0. A document to put them all togather is not completed yet. I plan to start a open source project base on current resource and the goal is to build a small and compact FreeBSD security appliance, most importantly cost effective. The first step is starting a close test before release it to public and discuss how to proceed. If you are FreeBSD power user and interested, you are welcome to contact me and receive a copy of current work. Any suggestions are always welcome. Vincent Chen ___ ³Ì·sª© Yahoo!©_¼¯§Y®É³q°T 7.0¡A§K¶Oºô¸ô¹q¸Ü¥ô§A¥´¡I http://messenger.yahoo.com.tw/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
News Article: FreeBSD Security
We might want to update the FreeBSD Press section. This is a recent article from SecurityFocus which discusses FreeBSD security vs Linux http://www.securityfocus.com/news/11230 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: News Article: FreeBSD Security
On Mon, Jul 04, 2005 at 07:37:02AM -0700, Remington L wrote: We might want to update the FreeBSD Press section. This is a recent article from SecurityFocus which discusses FreeBSD security vs Linux http://www.securityfocus.com/news/11230 Talk to [EMAIL PROTECTED] or submit a PR. Kris pgpnRtvUvdgS3.pgp Description: PGP signature
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-04:16.fetch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-04:16.fetch Security Advisory The FreeBSD Project Topic: Overflow error in fetch Category: core Module: fetch Announced: 2004-11-18 Credits:Colin Percival Affects:All FreeBSD versions. Corrected: 2004-11-18 12:02:13 UTC (RELENG_5, 5.3-STABLE) 2004-11-18 12:03:05 UTC (RELENG_5_3, 5.3-RELEASE-p1) 2004-11-18 12:04:29 UTC (RELENG_5_2, 5.2.1-RELEASE-p12) 2004-11-18 12:05:36 UTC (RELENG_5_1, 5.1-RELEASE-p18) 2004-11-18 12:05:50 UTC (RELENG_5_0, 5.0-RELEASE-p22) 2004-11-18 12:02:29 UTC (RELENG_4, 4.10-STABLE) 2004-11-18 12:06:06 UTC (RELENG_4_10, 4.10-RELEASE-p4) 2004-11-18 12:06:22 UTC (RELENG_4_9, 4.9-RELEASE-p13) 2004-11-18 12:06:36 UTC (RELENG_4_8, 4.8-RELEASE-p26) 2004-11-18 12:06:52 UTC (RELENG_4_7, 4.7-RELEASE-p28) FreeBSD only: YES For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://www.freebsd.org/security/. I. Background The fetch(1) utility is a tool for fetching files via FTP, HTTP, and HTTPS. II. Problem Description An integer overflow condition in the processing of HTTP headers can result in a buffer overflow. III. Impact A malicious server or CGI script can respond to an HTTP or HTTPS request in such a manner as to cause arbitrary portions of the client's memory to be overwritten, allowing for arbitrary code execution. IV. Workaround There is no known workaround for the affected application, although the ftp(1) application in the FreeBSD base system, and several applications in the FreeBSD Ports collection provide similar functionality and could be used in place of fetch(1). V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the RELENG_5_3, RELENG_5_2, RELENG_4_10, or RELENG_4_8 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.8, 4.10, 5.2, and 5.3 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:16/fetch.patch # ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:16/fetch.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/usr.bin/fetch # make obj make depend make make install 3) IMPORTANT NOTE to users of FreeBSD Update: FreeBSD Update (security/freebsd-update in the FreeBSD Ports collection) is a binary security update system for the FreeBSD base system. It is not supported or endorsed by the FreeBSD Security team, but its author has requested that the following note be included in this advisory: FreeBSD Update uses the fetch(1) utility for downloading security updates to the FreeBSD base system. While these updates are cryptographically signed, and FreeBSD Update is therefore immune from most attacks, it is exposed to this vulnerability since the files must be fetched before their integrity can be verified. As a workaround, FreeBSD Update can be made to use the ftp(1) utility for downloading updates as follows: # sed -i.bak -e 's/fetch -qo/ftp -o/' /usr/local/sbin/freebsd-update # freebsd-update fetch # mv /usr/local/sbin/freebsd-update.bak /usr/local/sbin/freebsd-update # freebsd-update install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_4 src/usr.bin/fetch/fetch.c 1.10.2.28 RELENG_4_10 src/UPDATING 1.73.2.90.2.5 src/sys/conf/newvers.sh 1.44.2.34.2.6 src/usr.bin/fetch/fetch.c 1.10.2.23.2.1 RELENG_4_9 src/UPDATING 1.73.2.89.2.14 src/sys/conf/newvers.sh 1.44.2.32.2.14 src/usr.bin/fetch/fetch.c 1.10.2.21.2.1 RELENG_4_8 src/UPDATING 1.73.2.80.2.29 src/sys/conf/newvers.sh 1.44.2.29.2.27 src/usr.bin/fetch/fetch.c 1.10.2.20.2.1 RELENG_4_7 src/UPDATING 1.73.2.74.2.32 src/sys/conf/newvers.sh
freebsd-security-announce
is this list active ? i am subscribed to it but received no emails from it in the past three months . anyone knows ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-security-announce
On Tue, Aug 31, 2004 at 08:44:43AM -0400, Moti Levy wrote: is this list active ? i am subscribed to it but received no emails from it in the past three months . anyone knows ? It doesn't appear in the list of FreeBSD mailing lists at: http://lists.freebsd.org/mailman/listinfo which suggests that it has gone the way of all flesh. Perhaps [EMAIL PROTECTED] or [EMAIL PROTECTED] would serve you better. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgpfC8GUQomYw.pgp Description: PGP signature
Re: freebsd-security-announce
Matthew Seaman wrote: On Tue, Aug 31, 2004 at 08:44:43AM -0400, Moti Levy wrote: is this list active ? i am subscribed to it but received no emails from it in the past three months . anyone knows ? It doesn't appear in the list of FreeBSD mailing lists at: http://lists.freebsd.org/mailman/listinfo which suggests that it has gone the way of all flesh. Perhaps [EMAIL PROTECTED] or [EMAIL PROTECTED] would serve you better. Cheers, Matthew i am subscribed t notifications as well , with two diffrent email address . still no luck :-( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-security-announce
On Tue, Aug 31, 2004 at 09:02:23AM -0400, Moti Levy wrote: It doesn't appear in the list of FreeBSD mailing lists at: http://lists.freebsd.org/mailman/listinfo which suggests that it has gone the way of all flesh. Perhaps [EMAIL PROTECTED] or [EMAIL PROTECTED] would serve you better. Cheers, Matthew i am subscribed t notifications as well , with two diffrent email address . still no luck :-( http://lists.freebsd.org/pipermail/freebsd-security-notifications/ There haven't been any security notifications recently, that's why you're not receiving any mail. -Radek ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd security patches
Hy I want to know more freebsd contributors' / users' websites. I searched a lot for links like: http://www.0xfce3.net/files/freebsd/ or http://garage.freebsd.pl/ (which contains a lot if interesting security related patches/programs) Google is of no help ... I can scarcely find one or two interesting sites ... Can people reading this mail submit freebsd security related websites ? (related to unnoficial kernel patches, file patches or programms) Please cc me the replies. Thank you, Bogdan __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
About FreeBSD Security Advisory FreeBSD-SA-04:11.msync
** Reply to note from FreeBSD Security Advisories [EMAIL PROTECTED] Wed, 26 May 2004 13:32:51 +0200 (CEST) From /usr/src/UPDATING: NOTE: In some cases involving NFS, the incorrect behaviour may actually be preferrable. Setting the vm.old_msync sysctl variable to 1 will revert msync(2) to its old behaviour. Just wondering what this means... bye Thanks av. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
/usr/src/UPDATING vs FreeBSD Security Advisory FreeBSD-SA-04:04.tcp
Hello, I've just (with cvsup) started upgrading one of my boxes in line with the recent advisory (FreeBSD Security Advisory FreeBSD-SA-04:04.tcp), and I'm at the point where I am reading /usr/src/UPDATING as per all recommendations from the HandBook to various user group advisories. However, I noticed that there is no mention of this specific advisory anywhere in UPDATING. So.., have I missed something? Here's what I did: - 1] su to root 2] cd /usr/share/examples/cvsup 3] Edit stable-supfile - changed default_host to read *default host=cvsup.uk.FreeBSD.org 4] Ran cvsup stable-supfile Aren't details of this advisory (and others?) supposed to be in /usr/src/UPDATING? I only askbecause I'd not want to proceed from this point only to realise later on that the system *wasn't* patched after all. I'd appreciate some advice, or pointer to some change in procedure that I might have missed somewhere along the line, please. Thanks for the time. Regards, Stacey ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/UPDATING vs FreeBSD Security Advisory FreeBSD-SA-04:04.tcp
I've just (with cvsup) started upgrading one of my boxes in line with the recent advisory (FreeBSD Security Advisory FreeBSD-SA-04:04.tcp), and I'm at the point where I am reading /usr/src/UPDATING as per all recommendations from the HandBook to various user group advisories. Aren't details of this advisory (and others?) supposed to be in /usr/src/UPDATING? I only askbecause I'd not want to proceed from this point only to realise later on that the system *wasn't* patched after all. UPDATING is not the place for this. You'll have to check the revisions of the files manually against those in the advisory. -- Cordula's Web. http://www.cordula.ws/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/src/UPDATING vs FreeBSD Security Advisory FreeBSD-SA-04:04.tcp
Hello, Thanks for the reply. - Original Message - From: Cordula's Web [EMAIL PROTECTED] To: To [EMAIL PROTECTED] Date: Sat, 06 Mar, 2004 10:51 GMT Subject: Re: /usr/src/UPDATING vs FreeBSD Security Advisory FreeBSD-SA-04:04.tcp I've just (with cvsup) started upgrading one of my boxes in line with the recent advisory (FreeBSD Security Advisory FreeBSD-SA-04:04.tcp), and I'm at the point where I am reading /usr/src/UPDATING as per all recommendations from the HandBook to various user group advisories. Aren't details of this advisory (and others?) supposed to be in /usr/src/UPDATING? I only askbecause I'd not want to proceed from this point only to realise later on that the system *wasn't* patched after all. UPDATING is not the place for this. You'll have to check the revisions of the files manually against those in the advisory. Okay.., cheers for that. I appreciate your taking the time. Regards, Stacey -- Cordula's Web. http://www.cordula.ws/ -- Stacey Roberts B. Sc (HONS) Computer Science Web: www.vickiandstacey.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Security Advisory FreeBSD-SA-04:01.mksnap_ffs part 2
hi i read FreeBSD Security Advisory FreeBSD-SA-04:01.mksnap_ffs and have question about this workaround: /bin/rm /sbin/mksnap_ffs isn't better to do: /bin/chmod u-s /sbin/mksnap_ffs i think that suid flag is dangerous on this program not program as is and when suid flag is down program is clear for everyone except root if is dangerous program, so erase it isn't good workaround, because every user can compile mksnap_ffs from source but suid flag can give only root thank and bye -- The ancient Greeks' concept of a ``personal daemon'' was similar to the modern concept of a ``guardian angel'' --- ``eudaemonia'' is the state of being helped or protected by a kindly spirit. As a rule, UNIX systems seem to be infested with both daemons and demons. [Evi Nemeth] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD security ....
Dear All , Is it possible that i give a Normal (without wheel rights) user to access my server using ftp ,and he can only browse thru his home directory not above that .If it is possbile pls reply me . Shrikant ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD security ....
On Tue, 28 Oct 2003, Shrikant wrote: Dear All , Is it possible that i give a Normal (without wheel rights) user to access my server using ftp ,and he can only browse thru his home directory not above that .If it is possbile pls reply me . This is more to do with the FTP server than normal access. If you install proftpd you can lock the person in their HomeDirectory using DefaultRoot ~ Also some software will lock someone in if you change their home directory from /home/user to /home/./user HTH Rus -- w: http://www.jvps.com | Linux + FreeBSD Servers from $15/mo e: [EMAIL PROTECTED]| Dedicated Servers from $119/mo t: +44 7919 373537 | email: [EMAIL PROTECTED] t: 1-888-327-6330 | email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD security ....
On October 28, 2003 4:34 am, Shrikant wrote: Dear All , Is it possible that i give a Normal (without wheel rights) user to access my server using ftp ,and he can only browse thru his home directory not above that .If it is possbile pls reply me . If you create the file /etc/ftpchroot and put the name of the user in that file (one name per line), the ftp daemon in the base install will chroot the user to their home directory. For exact details and more options, read the ftpchroot manual page by typing man ftpchroot at a shell prompt. Regards, Ed -- There are people who cheat on their spouse but not at cards, and vice versa, and both and neither. Reputation is not necessarily portable from one situation to another, and it's not easily expressed. --Clay Shirkey. (http://www.shirky.com/writings/group_enemy.html) It has been said that man is a rational animal. All my life I have been searching for evidence which could support this. --Bertrand Russell. The American empire is ideological, not territorial. We are the most ideological people in the world, and we are so united in our view that we don't understand there can be other views. --Lt. Gen. William Odom, ret. (Former Director of NSA). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Full-Disclosure] FreeBSD Security AdvisoryFreeBSD-SA-03:14.arp [REVISED]
The following patch has been verified to apply to FreeBSD 5-CURRENT, 4.9-PRERELEASE, and 4.8 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch.asc patch assume you didn't apply the original patch? patch /var/tmp/arp.patch Hmm... Looks like a new-style context diff to me... The text leading up to this was: -- |Index: sys/netinet/if_ether.c |=== |RCS file: /home/ncvs/src/sys/netinet/if_ether.c,v |retrieving revision 1.104 |retrieving revision 1.104.2.1 |diff -c -p -r1.104 -r1.104.2.1 |*** sys/netinet/if_ether.c 4 Mar 2003 23:19:52 - 1.104 |--- sys/netinet/if_ether.c 23 Sep 2003 20:08:42 - 1.104.2.1 -- Patching file sys/netinet/if_ether.c using Plan A... Hunk #1 failed at 918. 1 out of 1 hunks failed--saving rejects to sys/netinet/if_ether.c.rej done -- Michael Scheidell, CEO SECNAP Network Security, LLC Sales: 866-SECNAPNET / (1-866-732-6276) Main: 561-368-9561 / www.secnap.net Looking for a career in Internet security? http://www.secnap.net/employment/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
wrong link refference in the freebsd security How-To
hey there, Browsing the FreeBSD Security How-To pages i've found a wrong reference. http://people.freebsd.org/~jkb/howto.html#cvs In the relaed links sections you point to FreeBSD ipfw Configuration Page: http://www.metronet.com/~pgilley/freebsd/ipfw which does no longer exist. kind regards, -michael -- [EMAIL PROTECTED] Key fingerprint = 8E06 D29C EFC5 7B9A C5FB EC2F DC74 A106 ED35 857F /~\ The ASCII \ / Ribbon Campaign X Against HTML / \ Email! pgp0.pgp Description: PGP signature
Re: Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: As per this announcement I updated my source tree to 'date=2003.03.08.10.10.00' picking a date later than the Mar 4th date of FreeBSD-SA-03:04. My question is that I get: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RC #0: Sun Mar 9 23:03:55 EST 2003 Does the label not apply if I specify a date? Does the 4.8-RC #0 represent a problem? I did get the correct version of sendmail. This is a FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#RELEASE-CANDIDATE mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
Got it and thank you to all who replied. It is my memory that with some builds I have gotten something other than #0. But maybe that was from building something other than RELENG_4. I the sendmail fix was important enough where I felt the need for some reassurance. Thanks again. On Mon, 10 Mar 2003, Mike Meyer wrote: In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: As per this announcement I updated my source tree to 'date=2003.03.08.10.10.00' picking a date later than the Mar 4th date of FreeBSD-SA-03:04. My question is that I get: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RC #0: Sun Mar 9 23:03:55 EST 2003 Does the label not apply if I specify a date? Does the 4.8-RC #0 represent a problem? I did get the correct version of sendmail. This is a FAQ: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#RELEASE-CANDIDATE mike -- Mike Meyer [EMAIL PROTECTED]http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. _ Douglas Denault [EMAIL PROTECTED] Voice: 301-469-8766 Fax: 301-469-0601 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: Got it and thank you to all who replied. It is my memory that with some builds I have gotten something other than #0. But maybe that was from building something other than RELENG_4. I the sendmail fix was important enough where I felt the need for some reassurance. The #0 is a counter of the number of builds done in that kernel build directory. You somehow started with a clean directory this time, so the number was reset to zero. If you build that kernel again - with or without cvsup - without cleaning out the directory, it will go to 1, then 2, and so on. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
I cleaned /usr/obj/usr/... but not /usr/src which was at some version of 4.7. Also my root partition is a bit small so I played some games with /modules /modules.old and kernel.old. The count is driven off one of those? I did not mess with anything in /usr/src including /sys/../compile/. On Mon, 10 Mar 2003, Mike Meyer wrote: In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: Got it and thank you to all who replied. It is my memory that with some builds I have gotten something other than #0. But maybe that was from building something other than RELENG_4. I the sendmail fix was important enough where I felt the need for some reassurance. The #0 is a counter of the number of builds done in that kernel build directory. You somehow started with a clean directory this time, so the number was reset to zero. If you build that kernel again - with or without cvsup - without cleaning out the directory, it will go to 1, then 2, and so on. mike -- Mike Meyer [EMAIL PROTECTED]http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. _ Douglas Denault [EMAIL PROTECTED] Voice: 301-469-8766 Fax: 301-469-0601 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
[Context lost to top posting] In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: I cleaned /usr/obj/usr/... but not /usr/src which was at some version of 4.7. Also my root partition is a bit small so I played some games with /modules /modules.old and kernel.old. The count is driven off one of those? Cleaning out /usr/obj/ will reset the counter, as the build directory for the *kernel targets is in /usr/obj/usr/src/sys. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
As per this announcement I updated my source tree to 'date=2003.03.08.10.10.00' picking a date later than the Mar 4th date of FreeBSD-SA-03:04. From the announcement: 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_0, RELENG_4_7, or RELENG_4_6 security branch dated after the correction date (5.0-RELEASE-p4, 4.7-RELEASE-p7, or 4.6.2-RELEASE-p10, respectively). [NOTE: At the time of this writing, the FreeBSD 4-STABLE branch is labeled `4.8-RC1'.] My question is that I get: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RC #0: Sun Mar 9 23:03:55 EST 2003 Does the label not apply if I specify a date? Does the 4.8-RC #0 represent a problem? I did get the correct version of sendmail. _ Douglas Denault [EMAIL PROTECTED] Voice: 301-469-8766 Fax: 301-469-0601 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Upgrading for FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
On Mon, 10 Mar 2003 at 00:47:59 -0500, [EMAIL PROTECTED] wrote: As per this announcement I updated my source tree to 'date=2003.03.08.10.10.00' picking a date later than the Mar 4th date of FreeBSD-SA-03:04. From the announcement: 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_0, RELENG_4_7, or RELENG_4_6 security branch dated after the correction date (5.0-RELEASE-p4, 4.7-RELEASE-p7, or 4.6.2-RELEASE-p10, respectively). [NOTE: At the time of this writing, the FreeBSD 4-STABLE branch is labeled `4.8-RC1'.] My question is that I get: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RC #0: Sun Mar 9 23:03:55 EST 2003 Does the label not apply if I specify a date? Does the 4.8-RC #0 represent a problem? I did get the correct version of sendmail. No, the label of RC1 doesn't apply if you cvsup and build/install world, it only applies to snapshots and ISOs for QA purposes. If you update build/install world you'll only see RC. This is normal, and you're not seeing anything out of the ordinary. - jim -- - jim mock. email: [EMAIL PROTECTED] web: http://soupnazi.org - - freebsd project: [EMAIL PROTECTED]opendarwin: [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
Anybody know how we should approach this for older versions of FreeBSD? Is
upgrading source and rebuilding the only way? I was wondering if there
were binary versions or patches for older versions so we don't have
upgrade, rebuild and reboot.
At 09:11 AM 3/3/2003 -0800, FreeBSD Security Advisories, you wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
=
FreeBSD-SA-03:04.sendmail Security Advisory
The FreeBSD Project
Topic: sendmail header parsing buffer overflow
Category: contrib
Module: contrib_sendmail
Announced: 2003-03-03
Credits:Mark Dowd (ISS)
Affects:All releases prior to 4.8-RELEASE and 5.0-RELEASE-p4
FreeBSD 4-STABLE prior to the correction date
Corrected: 2003-03-03
FreeBSD only: NO
I. Background
FreeBSD includes sendmail(8), a general purpose internetwork mail
routing facility, as the default Mail Transfer Agent (MTA).
II. Problem Description
ISS has identified a buffer overflow that may occur during header
parsing in all versions of sendmail after version 5.79.
In addition, Sendmail, Inc. has identified and corrected a defect in
buffer handling within sendmail's RFC 1413 ident protocol support.
III. Impact
A remote attacker could create a specially crafted message that may
cause sendmail to execute arbitrary code with the privileges of the
user running sendmail, typically root. The malicious message might be
handled (and therefore the vulnerability triggered) by the initial
sendmail MTA, any relaying sendmail MTA, or by the delivering sendmail
process. Exploiting this defect is particularly difficult, but is
believed to be possible.
The defect in the ident routines is not believed to be exploitable.
IV. Workaround
There is no workaround, other than disabling sendmail.
V. Solution
Do one of the following:
1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_0,
RELENG_4_7, or RELENG_4_6 security branch dated after the correction
date (5.0-RELEASE-p4, 4.7-RELEASE-p7, or 4.6.2-RELEASE-p10,
respectively).
[NOTE: At the time of this writing, the FreeBSD 4-STABLE branch is
labeled `4.8-RC1'.]
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 5.0, 4.7,
and 4.6 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch /path/to/patch
# cd /usr/src/lib/libsm
# make obj make depend make
# cd /usr/src/lib/libsmutil
# make obj make depend make
# cd /usr/src/usr.sbin/sendmail
# make obj make depend make make install
3) For i386 systems only, a patched sendmail binary is available.
Select the correct binary based on your FreeBSD version and whether or
not you want STARTTLS support. If you want STARTTLS support, you must
have the crypto distribution installed.
a) Download the relevant binary from the location below, and verify
the detached PGP signature using your PGP utility.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.6-i386-crypto.bin.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.6-i386-crypto.bin.gz.asc
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.6-i386-nocrypto.bin.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.6-i386-nocrypto.bin.gz.asc
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.7-i386-crypto.bin.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.7-i386-crypto.bin.gz.asc
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.7-i386-nocrypto.bin.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-4.7-i386-nocrypto.bin.gz.asc
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-5.0-i386-crypto.bin.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-5.0-i386-crypto.bin.gz.asc
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-5.0-i386-nocrypto.bin.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:04/sendmail-5.0-i386-nocrypto.bin.gz.asc
b) Install the binary. Execute the following commands as root.
Note that these examples utilizes the FreeBSD 4.7 crypto binary.
Substitute BINARYGZ with the file name which you downloaded in
step (a).
# BINARYGZ=/path/to/sendmail-4.7-i386-crypto.bin.gz
# gunzip ${BINARYGZ}
# install -s -o root -g smmsp -m 2555 ${BINARYGZ%.gz}
/usr/libexec/sendmail/sendmail
c) Restart sendmail. Execute the following command as root.
# /bin/sh /etc/rc.sendmail restart
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD
Re: FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
On Mon, Mar 03, 2003 at 03:56:40PM -0600, Oscar Ricardo Silva wrote: Anybody know how we should approach this for older versions of FreeBSD? Is upgrading source and rebuilding the only way? I was wondering if there were binary versions or patches for older versions so we don't have upgrade, rebuild and reboot. What you see in the advisory is all that is provided by FreeBSD. If you're on an older release, it's not supported any longer and you need to figure out how to fix it on your own. That may involve upgrading to a supported release, or manually fixing the problem described in the advisory. In this case you can probably disable the base system sendmail and use the sendmail port. Kris pgp0.pgp Description: PGP signature
Re: FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail
In [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] typed: On Mon, Mar 03, 2003 at 03:56:40PM -0600, Oscar Ricardo Silva wrote: Anybody know how we should approach this for older versions of FreeBSD? Is upgrading source and rebuilding the only way? I was wondering if there were binary versions or patches for older versions so we don't have upgrade, rebuild and reboot. What you see in the advisory is all that is provided by FreeBSD. If you're on an older release, it's not supported any longer and you need to figure out how to fix it on your own. That may involve upgrading to a supported release, or manually fixing the problem described in the advisory. In this case you can probably disable the base system sendmail and use the sendmail port. Or the postfix port, or the qmail port, or the exim port. At least two of those three have had zero security problems, and it's probably true for all three of them. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
