aboutsummaryrefslogtreecommitdiffstats
path: root/polish/security/2004/dsa-453.wml
blob: 1e70c970020c60c3618cec33f1aaaebd2f913a28 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
#use wml::debian::translation-check translation="1.6"
<define-tag description>wadliwa funkcja i opró¿nienie TLB</define-tag>
<define-tag moreinfo>
<p>Paul Starzetz i Wojciech Purczynski z isec.pl <a
href="http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt">odkryli</a>
powa¿ne naruszenie bezpieczeñstwa w kodzie Linuksa zarz±dzaj±cym pamiêci± 
wewn±trz wywo³ania systemowego mremap(2). Z powodu zbyt wczesnego 
opró¿niania TLB (Translation Lookaside Buffer, cache adresów) istnieje
mo¿liwo¶æ spowodowania lokalnego z³amania konta root przez atakuj±cego.
</p>

<p>Podatne na atak s± wy³±cznie indywidualne serie wersji j±der 2.4.x i 2.2.x.
Poprzednio przypuszczali¶my, ¿e to naruszenie bezpieczeñstwa w 2.4.x nie istnieje
w 2.2.x, co w dalszym ci±gu jest prawd±. Jednak okaza³o siê, ¿e (raczej) drugie naruszenie
bezpieczeñstwa odnosi siê rzeczywi¶cie do 2.2.x ale nie do 2.4.x, oczywi¶cie z innym
exploitem.</p>

<p>W dystrybucji stabilnej (woody) powy¿szy problem zosta³ wyeliminowany
w nastêpuj±cych wersjach i architekturach:</p>

<table>
  <tr>
    <th>pakiet</th>
    <th>architektura</th>
    <th>wersja</th>
  </tr>
  <tr>
    <td>kernel-source-2.2.20</td>
    <td>source</td>
    <td>2.2.20-5woody3</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-i386</td>
    <td>i386</td>
    <td>2.2.20-5woody5</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-reiserfs-i386</td>
    <td>i386</td>
    <td>2.2.20-4woody1</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-amiga</td>
    <td>m68k</td>
    <td>2.20-4</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-atari</td>
    <td>m68k</td>
    <td>2.2.20-3</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-bvme6000</td>
    <td>m68k</td>
    <td>2.2.20-3</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-mac</td>
    <td>m68k</td>
    <td>2.2.20-3</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-mvme147</td>
    <td>m68k</td>
    <td>2.2.20-3</td>
  </tr>
  <tr>
    <td>kernel-image-2.2.20-mvme16x</td>
    <td>m68k</td>
    <td>2.2.20-3</td>
  </tr>
  <tr>
    <td>kernel-patch-2.2.20-powerpc</td>
    <td>powerpc</td>
    <td>2.2.20-3woody1</td>
  </tr>
</table>

<p>W dystrybucji niestabilnej (sid) powy¿szy problem bêdzie 
nied³ugo wyeliminowany dla tych architektur, które w dalszym ci±gu
s± dostarczane z pakietem j±dra 2.2.x.</p>

<p>Zalecamy aktualizacjê pakietu j±dra Linuksa</p>

<p><a href="CAN-2004-0077">Macierzowe zestawienie luk</a> dla CAN-2004-0077</p>

</define-tag>

# do not modify the following line
#include "$(ENGLISHDIR)/security/2004/dsa-453.data"

© 2014-2024 Faster IT GmbH | imprint | privacy policy