SA-05:06.iir

FreeBSD-SA-05:06.iir                                 Security Advisory
The FreeBSD Project

Temat: Złe prawa /dev/iir

Kategoria: core
Moduł: sys_dev
Ogłoszono: 2005-05-06
Podziękowania: Christian S.J. Peron
Podatne wersje: Wszystkie wydania FreeBSD 4.x od 4.6-RELEASE
Wszystkie wydania FreeBSD 5.x do 5.4-RELEASE
Poprawiono: 2005-05-06 02:33:46 UTC (RELENG_5, 5.4-STABLE)
2005-05-06 02:34:18 UTC (RELENG_5_4, 5.4-RELEASE)
2005-05-06 02:34:01 UTC (RELENG_5_3, 5.3-RELEASE-p11)
2005-05-06 02:32:54 UTC (RELENG_4, 4.11-STABLE)
2005-05-06 02:33:28 UTC (RELENG_4_11, 4.11-RELEASE-p5)
2005-05-06 02:33:12 UTC (RELENG_4_10, 4.10-RELEASE-p10)
Nazwa CVE: CAN-2005-1399

Dla pogłębienia informacji dotyczącej Ogłoszeń Bezpieczeństwa FreeBSD, włączając opisy pól powyżej, gałęzi bezpieczeństwa oraz poniższych sekcji proszę odwiedzić:
[URL:http://www.freebsd.org/security/]

0. Przęgląd historii

v1.0 2005-05-06 Początkowe wydanie
v1.1 2005-05-07 Aktualizacja podziękowań dla Andre Guibert de Bruet.

I. Podstawy

Sterownik irr(4) dostarcza wsparcie dla kontrolera RAID ( Intel Integrated RAID ) oraz kontroler ICP Vortex RAID.

II. Opis problemu

Domyślne prawa dla urządzenia /dev/irr umożliwiają nieuprzywilejowanym lokalnym użytkownikom włączyć urządzenie i wykonać wywołania ioctl

III. Wpływ

Nieprzywilejowany użytkownik może wysłac komendę do wspieranego urządzenia poprzez sterownik irr(4), co umożliwi zniszczenie danych i prawdopodobne odkrycie ich.

IV. Obejście

Systemy bez wsparcia poprzez sterownik irr(4) nie sa podatne na ten błąd. Na systemach które maja wsparcie, należy zmienic uprawnienia manualnie.

Jako root, należy wykonać poniższą komendę:

# chmod 0600 /dev/iir*

Na systemach z serii 5.x, należy sie upewnić że dane prawa będą takie same po restarcie maszyny:

# echo 'perm iir* 0600' >> /etc/devfs.conf
# echo 'devfs_enable="YES"' >> /etc/rc.conf

Jeżeli administrator utworzył dodatkowy węzeł urządzenia lub zamontował dodatkową instancję wykorzystując devfs(5) w innych miejscach systemu, powinien zwrócić uwagę i upewnić się czy inne węzły urządzeń nie są widoczne w tych przestrzeniach nazw lub podobnie chronione.

V. Rozwiązanie

1) Uaktualnić wadliwy system do 4-STABLE lub 5-STABLE, lub do RELENG_5_3, RELENG_4_11, RELENG_4_10 z danej gałęzi bezpieczeństwa wydanej po dacie poprawki.

2) Aby załatać obecny system:

Poniższe poprawki zostały sprawdzone w działaniu z FreeBSD 4.10,4.11 i 5.3.

a) Pobrać odpowiednią łatkę z lokalizacji podanych poniżej. Sprawdzić podpis PGP, narzędziem jakie posiadasz.

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:06/iir.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:06/iir.patch.asc

b) Wykonać będąc zalogowanym jako root:

# cd /usr/src
# patch < /path/to/patch

c) Przebudować cały system jak opisano w dokumentacji na stronie: <URL:http://www.freebsd.org/doc/handbook/makeworld.html>

Gałąź                                                           Wersja
Ścieżka
- -------------------------------------------------------------------------
RELENG_4
src/sys/dev/iir/iir_ctrl.c 1.2.2.5
RELENG_4_11
src/UPDATING 1.73.2.91.2.6
src/sys/conf/newvers.sh 1.44.2.39.2.9
src/sys/dev/iir/iir_ctrl.c 1.2.2.4.12.1
RELENG_4_10
src/UPDATING 1.73.2.90.2.11
src/sys/conf/newvers.sh 1.44.2.34.2.12
src/sys/dev/iir/iir_ctrl.c 1.2.2.4.10.1
RELENG_5
src/sys/dev/iir/iir_ctrl.c 1.15.2.2
RELENG_5_4
src/UPDATING 1.342.2.24.2.5
src/sys/dev/iir/iir_ctrl.c 1.15.2.1.2.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.14
src/sys/conf/newvers.sh 1.62.2.15.2.16
src/sys/dev/iir/iir_ctrl.c 1.15.4.1
- -------------------------------------------------------------------------

Najnowsza wersja jest dostępna pod adresem:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:06.iir.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)
iD8DBQFCfEXyFdaIBMps37IRAu6WAJ9qBjsIfH7GGPRiHsvXwlkuau5kswCfXhan
YhoUBZ4gHuIXJFM1gOEAyVk=
=zRAR
-----END PGP SIGNATURE-----

Hosting @mc2 || Copyright © 2024 FreeBSD - Inside. Wszelkie prawa zastrzeżone.