Показать полную графическую версию : вопросы безопасности
Хм... Слушайте, раз уж тема так называется - мне очень не хочется, чтобы мою систему кто-нить хакнул, поэтому - подскажите какую прогу, с помощью которой можно было бы искать руткиты и т.д. То есть, чтобы она как ipfw работала на фоне и не давала никому взломать мою Фри. :)
SantaXP
вообще-то FreeBSD неплохо защищена по-дефолту, но ежели хочется дополнений (в том числе по руткитам):
1) смотрим какой у Вас стоит securelevel и рихтуем, если надо
2) расставляем (если надо) и куда считаем нужным флаг schg
3) в /etc/fstab для /tmp устанавливаем: rw,noexec,nosuid,nodev,nosymfollow и nodev на все места, где не нужны dev (а не нужны они нигде, кроме /dev и мест, где организуется chroot, или jail-среда)
4) Если стоит ipfw, убедитесь в том, что у Вас на вход закрыто все, кроме необходимого, а большая часть необходимого открывается изнутри по запросу (динамические правила)
5) Правим /etc/sysctl.conf (защищаемся от DOS-атак, превращаем машину в черную дыру для nmap и Ko и т.д.)
# Предотвращение DoS атак в FreeBSD
net.inet.tcp.msl=время # время ожидания ACK в ответ на SYN-ACK или FIN-ACK в миллисекундах
net.inet.tcp.blackhole=2 # blackhole pings, traceroutes, etc. - все пакеты на закрытый порт отбрасываются без отсылки RST; (черная дыра)
net.inet.udp.blackhole=1 # отбрасывать пакеты для закрытых портов;
net.inet.icmp.icmplim=50 # защита от генерирование потока ответных пакетов,
#- максимальное количество ICMP Unreachable и TCP RST пакетов в секунду
6) если установлен демон ssh,
3-1) - правим (и проверяем /etc/ssh/sshd_config, обращаем внимание:
Port 22 # или тот, на котором хотите слушать
AllowUsers SantaXP # только этому пользователю
PermitEmptyPasswords no # нет пустым паролям (по-дефолту)
PermitRootLogin no # никаких рутовых входов (по-дефолту)
+ смотрите, что Вам кажется более безопасным - ключи, или пароли
3-2) правим /etc/hosts.allow, разрешая вход по ssh только с определенных ip (заодно правим нужное для других демонов)
7) Ставим программу portsentry и настраиваем ее на блокировку атакующих хостов (чтоб больше не лезли)
8) Установливаем программу chkrootkit и припишите в crontab:
0 3 * * * root (/usr/local/sbin/chkrootkit -q 2>&1 | mail -s "chkrootkit output" root)
9) не забываем читать логи (в aliases прописываем root: свой ник и даем команду newaliases
На самом деле можно защищаться и сильнее, вопрос, насколько это нужно (одно дело защита firewall, другое - внутреннего сервера, третье - рабочей машины :))
Belansky
05-07-2005, 09:04
SantaXP
Если Вас заинтересовали вопросы безопасности, можете почитать статью (http://unix.ginras.ru/bsd/adm002.html) Дрю Лавинь "Защита от троянов и руткитов."
в дополнние - еще несколько ссылок:
http://www.freebsd.org/security/security.html - FreeBSD Security Information
+ лучше бы подписаться на freebsd-security-notifications@freebsd.org (есть и другие листки рассылки)
Увеличение безопасности FreeBSD (http://www.opennet.ru/tips/sml/88.shtml) (советую читать вместе с обсуждениями - ссылки там же)
man 8 sshd (http://www.opennet.ru/man.shtml?topic=sshd&category=8&russian=0)
man 8 init
mar
Спасибо, будет время почитаю. :)
----
Хм... А ещё вопрос насчёт безопастности, а куда можно записать правила для ipfw, ибо я их записал в sh скрипт, но уже замучился его каждый раз вызывать...
----
Кстати, раз уж тема так называется - а почему считатеся, что сидеть в иксах под рутом - это суицид. И вообще, каким образом Иксы влия.т на безопастность???
SantaXP
По-дефолту слушают 6000 порт
SantaXP
Спасибо, будет время почитаю
вперед :) хотя кое-что (настроечные файлы см. выше пункты 1-9) стоит почитать заранее ;]
куда можно записать правила для ipfw
в /etc/rc.conf можно вставить строки:
firewall_enable="YES" #Запускаем при старте работу ipfw
firewall_script="путь_к_файлу_со_скриптом" #Скрипт с правилами ipfw
Насчет рута: вообще работать под рутом без надобности (не только в иксах) - это путь к суициду (системы). Мне приходилось помогать человеку восстанавливать систему после того, как он снес каталог /bin Как Вам такое? =) Ну, а в иксах еще проще, наверное, кликая мышкой, сделать что-нибуь не менее фатальное (все-таки, когда человек вводит команду в командной строке, есть ненулевой шанс задуматься :))
Ну, и, как всегда, на закуску несколько ссылок:
http://www.linux.org.ru/books/lor-faq/lorFAQ-12.html#ss12.7
http://www.linuxforum.ru/lofiversion/index.php/t3638.html
firewall_enable="YES" #Запускаем при старте работу ipfw
firewall_script="путь_к_файлу_со_скриптом" #Скрипт с правилами ipfw
Хм... У меня это указано... Хе... Дык, там стоит firewall_script="/etc/rc.firewall", видимо туда и надо записывать... А если указать на другой файл, я файрвол не испрчю, а то у меня есть подозрение, что /etc/rc.firewall содержит ещё кое-что необходимое для работы ipfw???
SantaXP
А если указать на другой файл, я файрвол не испрчю
не испортите, просто будут выполняться только те условия, которые в Вашем файле (или правьте /etc/rc.firewall - только сохраните оригинал =))
Belansky
08-07-2005, 12:23
Очередной патч (ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:16.zlib.asc) по безопасности.
FreeBSD-SA-05:16.zlib Security Advisory
The FreeBSD Project
Topic: Buffer overflow in zlib
Category: core
Module: libz
Announced: 2005-07-06
Credits: Tavis Ormandy
Affects: FreeBSD 5.3, FreeBSD 5.4
Corrected: 2005-07-06 14:01:11 UTC (RELENG_5, 5.4-STABLE)
2005-07-06 14:01:30 UTC (RELENG_5_4, 5.4-RELEASE-p4)
2005-07-06 14:01:52 UTC (RELENG_5_3, 5.3-RELEASE-p18)
CVE Name: CAN-2005-2096
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
zlib is a compression library used by numerous applications to provide
data compression/decompression routines.
II. Problem Description
An error in the handling of corrupt compressed data streams can result
in a buffer being overflowed.
III. Impact
By carefully crafting a corrupt compressed data stream, an attacker can
overwrite data structures in a zlib-using application. This may cause
the application to halt, causing a denial of service; or it may result
in the attacker gaining elevated privileges.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 5-STABLE, or to the RELENG_5_4 or
RELENG_5_3 security branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 5.3 and 5.4
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:16/zlib.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:16/zlib.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libz/
# make obj && make depend && make && make install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_5
src/lib/libz/inftrees.c 1.4.2.2
RELENG_5_4
src/UPDATING 1.342.2.24.2.13
src/sys/conf/newvers.sh 1.62.2.18.2.9
src/lib/libz/inftrees.c 1.4.6.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.21
src/sys/conf/newvers.sh 1.62.2.15.2.23
src/lib/libz/inftrees.c 1.4.4.1
Belansky
А эти патчи, они устанавливаются каждый по отдельности или последующий содержит все остальные изменения в системе из предыдущих???
И ещё - их инсталить обязательно? Насколько их неналичие на компе может отразиться на безопастности системы???
Belansky
08-07-2005, 20:03
SantaXP
А эти патчи, они устанавливаются каждый по отдельности или последующий содержит все остальные изменения в системе из предыдущих???
Каждый сам за себя. :) Тут нет понятия куммулятивных патчей, как в Windows. Каждый патч накладывается отдельно и пересобирается какая-либо часть системы. Либо, в результате обновления системы через cvsup измененные версии пропатченных файлов автоматически размещаются среди исходного кода системы. И тогда остается только пересобрать систему посредством make buildworld, make buildkernell и т.д.
И ещё - их инсталить обязательно? Насколько их неналичие на компе может отразиться на безопастности системы???
А это хозяин - барин. :) Критичность обнаруженной дыры смотрите в описании к патчу. В плане безопасности лучше перебдеть, чем недобдеть. :)
Belansky
Слушайте, вы я думаю в курсе, что у меня модем. Посему, вытянет ли мой модем при средней скорости от 4 до 6 (правда однажды было и 7, но не долго :) ) kb/s обновление системы через cvsup???
----
оффтоп: я многое слышал про cvsup, однако, что это а штука пока не понял. Это что-то вроде средства автоматизированного обновления системы???
Belansky
09-07-2005, 09:42
SantaXP
вытянет ли мой модем при средней скорости от 4 до 6 kb/s обновление системы через cvsup?
Легко и непринужденно. Дома у меня тоже dialup. Минут за 15-20 вся процедура заканчивается.
Это что-то вроде средства автоматизированного обновления системы?
Это средство синхронизации исходников системы и коллекции портов с удаленным cvsup-сервером по состоянию на какой-либо момент времени. Если прописать работу cvsup через cron, то будет автоматизированным средством. Подробнее о cvsup читайте в руководстве пользователя. И в разделе эта тему уже неоднократно обсуждалась.
Belansky
ОК, будет время - поищу спасибо... :)
Belansky
22-07-2005, 08:40
Очередное обновление по безопасности ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:17.devfs.asc
FreeBSD-SA-05:17.devfs Security Advisory
The FreeBSD Project
Topic: devfs ruleset bypass
Category: core
Module: devfs
Announced: 2005-07-20
Credits: Robert Watson
Affects: All FreeBSD 5.x releases
Corrected: 2005-07-20 13:35:44 UTC (RELENG_5, 5.4-STABLE)
2005-07-20 13:36:32 UTC (RELENG_5_4, 5.4-RELEASE-p5)
2005-07-20 13:37:27 UTC (RELENG_5_3, 5.3-RELEASE-p19)
CVE Name: CAN-2005-2218
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 jail(2) system call allows a system administrator to lock a process
and all of its descendants inside an environment with a very limited
ability to affect the system outside that environment, even for
processes with superuser privileges. It is an extension of, but
far more powerful than, the traditional UNIX chroot(2) system call.
The device file system, or devfs(5), provides access to kernel's device
namespace in the global file system namespace. This includes access to
to system devices such as storage devices, kernel and system memory
devices, BPF devices, and serial port devices. Devfs is is generally
mounted as /dev. Devfs rulesets allow an administrator to hide
certain device nodes; this is most commonly applied to a devfs mounted
for use inside a jail, in order to make devices inaccessible to
processes within that jail.
II. Problem Description
Due to insufficient parameter checking of the node type during device
creation, any user can expose hidden device nodes on devfs mounted
file systems within their jail. Device nodes will be created in the
jail with their normal default access permissions.
III. Impact
Jailed processes can get access to restricted resources on the host
system. For jailed processes running with superuser privileges this
implies access to all devices on the system. This level of access
can lead to information leakage and privilege escalation.
IV. Workaround
Unmount device file systems mounted inside jails. Note that certain
device nodes, such as /dev/null, may be required for some software to
function correctly.
This can be done by executing the following command as root:
umount -A -t devfs
Also, remove or comment out any lines in fstab(5) that reference
`devfs' and has a mount point within a jail, so that they will not be
re-mounted at next reboot.
Some device file systems might be busy, including the host's main /dev
file system, and processes accessing these must be shut down before
the device file system can be unmounted. The hosts main device file
system, mounted as /dev, should not be unmounted since it is required
for normal system operation.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 5-STABLE, or to the RELENG_5_4,
or RELENG_5_3 security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 5.3, and
5.4 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:17/devfs.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:17/devfs.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_5
src/sys/fs/devfs/devfs_vnops.c 1.73.2.2
RELENG_5_4
src/UPDATING 1.342.2.24.2.14
src/sys/conf/newvers.sh 1.62.2.18.2.10
src/sys/fs/devfs/devfs_vnops.c 1.73.2.1.2.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.22
src/sys/conf/newvers.sh 1.62.2.15.2.24
src/sys/fs/devfs/devfs_vnops.c 1.73.4.1
Belansky
27-07-2005, 23:27
Очередные обновления по безопасности.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:18.zlib.asc
FreeBSD-SA-05:18.zlib Security Advisory
The FreeBSD Project
Topic: Buffer overflow in zlib
Category: core
Module: libz
Announced: 2005-07-27
Credits: Markus Oberhumer
Affects: FreeBSD 5.3, FreeBSD 5.4
Corrected: 2005-07-27 08:41:44 UTC (RELENG_6, 6.0-BETA2)
2005-07-27 08:41:56 UTC (RELENG_5, 5.4-STABLE)
2005-07-27 08:42:16 UTC (RELENG_5_4, 5.4-RELEASE-p6)
2005-07-27 08:42:38 UTC (RELENG_5_3, 5.3-RELEASE-p20)
CVE Name: CAN-2005-1849
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/>.
NOTE WELL: The issue discussed in this advisory is distinct from the
issue discussed in the earlier advisory FreeBSD-SA-05:16.zlib, although
the impact is very similar.
I. Background
zlib is a compression library used by numerous applications to provide
data compression/decompression routines.
II. Problem Description
A fixed-size buffer is used in the decompression of data streams. Due
to erronous analysis performed when zlib was written, this buffer,
which was belived to be sufficiently large to handle any possible input
stream, is in fact too small.
III. Impact
A carefully constructed compressed data stream can result in zlib
overwriting some data structures. This may cause applications to halt,
resulting in a denial of service; or it may result in an attacker
gaining elevated privileges.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 5-STABLE, or to the RELENG_5_4 or
RELENG_5_3 security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 5.3, and 5.4
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:18/zlib.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:18/zlib.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libz/
# make obj && make depend && make && make install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_5
src/lib/libz/inftrees.h 1.1.1.5.2.1
RELENG_5_4
src/UPDATING 1.342.2.24.2.15
src/sys/conf/newvers.sh 1.62.2.18.2.11
src/lib/libz/inftrees.h 1.1.1.5.6.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.23
src/sys/conf/newvers.sh 1.62.2.15.2.25
src/lib/libz/inftrees.h 1.1.1.5.4.1
RELENG_6
src/lib/libz/inftrees.h 1.1.1.5.8.1
И еще.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:19.ipsec.asc
FreeBSD-SA-05:19.ipsec Security Advisory
The FreeBSD Project
Topic: Incorrect key usage in AES-XCBC-MAC
Category: core
Module: netinet6
Announced: 2005-07-27
Credits: Yukiyo Akisada, Yokogawa Electric Corporation
Affects: FreeBSD 5.3, FreeBSD 5.4
Corrected: 2005-07-27 08:41:44 UTC (RELENG_6, 6.0-BETA2)
2005-07-27 08:41:56 UTC (RELENG_5, 5.4-STABLE)
2005-07-27 08:42:16 UTC (RELENG_5_4, 5.4-RELEASE-p6)
2005-07-27 08:42:38 UTC (RELENG_5_3, 5.3-RELEASE-p20)
CVE Name: CAN-2005-2359
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
IPsec is a security protocol for the Internet Protocol networking
layer. It provides a combination of encryption and authentication of
system, using several possible cryptography algorithms.
II. Problem Description
A programming error in the implementation of the AES-XCBC-MAC algorithm
for authentication resulted in a constant key being used instead of the
key specified by the system administrator.
III. Impact
If the AES-XCBC-MAC algorithm is used for authentication in the absence
of any encryption, then an attacker may be able to forge packets which
appear to originate from a different system and thereby succeed in
establishing an IPsec session. If access to sensitive information or
systems is controlled based on the identity of the source system, this
may result in information disclosure or privilege escalation.
IV. Workaround
Do not use the AES-XCBC-MAC algorithm for authentication, or use it
together with some form of IPsec encryption.
Systems which do not use IPsec, use other algorithms, or have IPsec
encryption enabled are unaffected by this issue.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 5-STABLE, or to the RELENG_5_4 or
RELENG_5_3 security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 5.3 and 5.4
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:19/ipsec.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:19/ipsec.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_5
src/sys/netinet6/ah_aesxcbcmac.c 1.1.4.2
RELENG_5_4
src/UPDATING 1.342.2.24.2.15
src/sys/conf/newvers.sh 1.62.2.18.2.11
src/sys/netinet6/ah_aesxcbcmac.c 1.1.4.1.2.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.23
src/sys/conf/newvers.sh 1.62.2.15.2.25
src/sys/netinet6/ah_aesxcbcmac.c 1.1.6.1
RELENG_6
src/sys/netinet6/ah_aesxcbcmac.c 1.2.2.1
В системе по умолчанию присутствует второй root - toor. Вопрос такой: какой у него пароль по умолчанию, и, если этого пользователя убрать, нарушится ли какая-то функциональность в системе? Нужно ли после 'отчисления' этого пользователя перестраивать базу данных паролей?
Belansky
01-08-2005, 10:38
Demiurg
По поводу пользователя toor почитайте здесь (http://www.freebsd.org/doc/ru_RU.KOI8-R/books/faq/security.html#TOOR-ACCOUNT) и здесь (http://forum.oszone.net/showthread.php?t=16011&highlight=toor).
Belansky
13-09-2005, 09:21
Что-то у нас упорно про заплатку от седьмого сентября сего года молчат? :)
FreeBSD-SA-05:20.cvsbug Security Advisory
The FreeBSD Project
Topic: Race condition in cvsbug
Category: contrib
Module: contrib_cvs
Announced: 2005-09-07
Credits: Marcus Meissner
Affects: All FreeBSD releases
Corrected: 2005-09-07 13:43:05 UTC (RELENG_6, 6.0-BETA5)
2005-09-07 13:43:23 UTC (RELENG_5, 5.4-STABLE)
2005-09-07 13:43:36 UTC (RELENG_5_4, 5.4-RELEASE-p7)
2005-09-09 19:26:19 UTC (RELENG_5_3, 5.3-RELEASE-p22)
2005-09-07 13:44:06 UTC (RELENG_4, 4.11-STABLE)
2005-09-07 13:44:20 UTC (RELENG_4_11, 4.11-RELEASE-p12)
2005-09-09 19:24:22 UTC (RELENG_4_10, 4.10-RELEASE-p18)
CVE Name: CAN-2005-2693
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/>.
0. Revision History
v1.0 2005-07-07 Initial release.
v1.1 2005-07-09 Additional related issues fixed in FreeBSD 4.10 and 5.3.
I. Background
cvsbug(1) is a utility for reporting problems in the CVS revision
control system. It is based on the GNATS send-pr(1) utility.
II. Problem Description
A temporary file is created, used, deleted, and then re-created with
the same name. This creates a window during which an attacker could
replace the file with a link to another file. While cvsbug(1) is based
on the send-pr(1) utility, this problem does not exist in the version
of send-pr(1) distributed with FreeBSD.
In FreeBSD 4.10 and 5.3, some additional problems exist concerning
temporary file usage in both cvsbug(1) and send-pr(1).
III. Impact
A local attacker could cause data to be written to any file to which
the user running cvsbug(1) (or send-pr(1) in FreeBSD 4.10 and 5.3) has
write access. This may cause damage in itself (e.g., by destroying
important system files or documents) or may be used to obtain elevated
privileges.
IV. Workaround
Do not use the cvsbug(1) utility on any system with untrusted users.
Do not use the send-pr(1) utility on a FreeBSD 4.10 or 5.3 system with
untrusted users.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the
RELENG_5_4, RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch
dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 4.10,
4.11, 5.3, and 5.4 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 4.10]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:20/cvsbug410.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:20/cvsbug410.patch.asc
[FreeBSD 5.3]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:20/cvsbug53.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:20/cvsbug53.patch.asc
[FreeBSD 4.11 and 5.4]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:20/cvsbug.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:20/cvsbug.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/gnu/usr.bin/cvs/cvsbug
# make obj && make depend && make && make install
# cd /usr/src/gnu/usr.bin/send-pr
# make obj && make depend && make && make 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/contrib/cvs/src/cvsbug.in 1.1.1.1.2.4
RELENG_4_11
src/UPDATING 1.73.2.91.2.13
src/sys/conf/newvers.sh 1.44.2.39.2.16
src/contrib/cvs/src/cvsbug.in 1.1.1.1.2.3.2.1
RELENG_4_10
src/UPDATING 1.73.2.90.2.19
src/sys/conf/newvers.sh 1.44.2.34.2.20
src/contrib/cvs/src/cvsbug.in 1.1.1.1.2.2.6.2
src/gnu/usr.bin/send-pr/send-pr.sh 1.13.2.13.2.1
RELENG_5
src/contrib/cvs/src/cvsbug.in 1.1.1.3.2.1
RELENG_5_4
src/UPDATING 1.342.2.24.2.16
src/sys/conf/newvers.sh 1.62.2.18.2.12
src/contrib/cvs/src/cvsbug.in 1.1.1.3.6.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.25
src/sys/conf/newvers.sh 1.62.2.15.2.27
src/contrib/cvs/src/cvsbug.in 1.1.1.3.4.1
src/gnu/usr.bin/send-pr/send-pr.sh 1.35.6.1
RELENG_6
src/contrib/cvs/src/cvsbug.in 1.1.1.3.8.1
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.