[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[DONE] wml://security/2001/dsa-0{65,79,86}.wml

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- --- english/security/2001/dsa-065.wml	2004-08-04 04:50:42.000000000 +0600
+++ russian/security/2001/dsa-065.wml	2016-07-07 17:20:59.169319983 +0500
@@ -1,30 +1,31 @@
- -<define-tag description>remote file append/creation</define-tag>
+#use wml::debian::translation-check translation="1.4" maintainer="Lev Lamberov"
+<define-tag description>Ñ?далÑ?нное Ñ?оздание/допиÑ?Ñ?вание Ñ?айла</define-tag>
 <define-tag moreinfo>
- -Michal Zalewski discovered that Samba does not properly validate
- -NetBIOS names from remote machines.
+Ð?иÑ?ал Ð?алевÑ?кий обнаÑ?Ñ?жил, Ñ?Ñ?о Samba непÑ?авилÑ?но вÑ?полнÑ?еÑ? пÑ?овеÑ?кÑ?
+имÑ?н NetBIOS Ñ? Ñ?далÑ?ннÑ?Ñ? маÑ?ин.
 
- -<p>By itself that is not a problem, except if Samba is configured to
- -write log-files to a file that includes the NetBIOS name of the
- -remote side by using the `%m' macro in the `log file' command. In
- -that case an attacker could use a NetBIOS name like '../tmp/evil'.
- -If the log-file was set to "/var/log/samba/%s" Samba would then
- -write to /var/tmp/evil.
- -
- -<p>Since the NetBIOS name is limited to 15 characters and the `log
- -file' command could have an extension to the filename the results
- -of this are limited. However if the attacker is also able to create
- -symbolic links on the Samba server they could trick Samba into
- -appending any data they want to all files on the filesystem which
- -Samba can write to.
+<p>Само по Ñ?ебе Ñ?Ñ?о не Ñ?влÑ?еÑ?Ñ?Ñ? пÑ?облемой за иÑ?клÑ?Ñ?ением Ñ?ого Ñ?лÑ?Ñ?аÑ?, когда Samba
+наÑ?Ñ?Ñ?оена на запиÑ?Ñ? Ñ?айлов жÑ?Ñ?нала в Ñ?айл, вклÑ?Ñ?аÑ?Ñ?ий имÑ? NetBIOS
+Ñ?далÑ?нной Ñ?Ñ?оÑ?онÑ? пÑ?Ñ?Ñ?м иÑ?полÑ?зованиÑ? макÑ?оÑ?а `%m' в команде `log file'. Ð?
+Ñ?Ñ?ом Ñ?лÑ?Ñ?ае злоÑ?мÑ?Ñ?ленник можеÑ? иÑ?полÑ?зоваÑ?Ñ? имÑ? NetBIOS вида '../tmp/evil'.
+Ð?Ñ?ли опÑ?иÑ? вÑ?боÑ?а Ñ?айла жÑ?Ñ?нала имееÑ? знаÑ?ение "/var/log/samba/%s", Ñ?о Samba
+попÑ?Ñ?аеÑ?Ñ?Ñ? вÑ?полниÑ?Ñ? запиÑ?Ñ? в /var/tmp/evil.
+
+<p>Ð?оÑ?колÑ?кÑ? имÑ? NetBIOS огÑ?аниÑ?енно 15 Ñ?имволами, а команда `log
+file' можеÑ? добавлÑ?Ñ?Ñ? Ñ?аÑ?Ñ?иÑ?ение к имени Ñ?айла, Ñ?о Ñ?езÑ?лÑ?Ñ?аÑ?Ñ? подобного дейÑ?Ñ?виÑ?
+злоÑ?мÑ?Ñ?ленника огÑ?аниÑ?енÑ?. Тем не менее, еÑ?ли злоÑ?мÑ?Ñ?ленник Ñ?ак же Ñ?поÑ?обен Ñ?оздаÑ?Ñ?
+Ñ?имволÑ?нÑ?е Ñ?Ñ?Ñ?лки на Ñ?еÑ?веÑ?е Samba, Ñ?о он можеÑ? иÑ?полÑ?зоваÑ?Ñ? Samba длÑ?
+добавлениÑ? лÑ?бÑ?Ñ? даннÑ?Ñ? в лÑ?бой Ñ?айл Ñ?айловой Ñ?иÑ?Ñ?емÑ?, оÑ?кÑ?Ñ?Ñ?Ñ?й длÑ? запиÑ?и
+Samba.
 
- -<p>The Debian GNU/Linux packaged version of Samba has a safe
- -configuration and is not vulnerable.
+<p>Ð?еÑ?Ñ?иÑ? Samba в Debian GNU/Linux имееÑ? безопаÑ?нÑ?Ñ? наÑ?Ñ?Ñ?ойкÑ?
+и не подвеÑ?жена данной Ñ?Ñ?звимоÑ?Ñ?и.
 
- -<p>As temporary workaround for systems that are vulnerable change all
- -occurrences of the `%m' macro in smb.conf to `%l' and restart Samba.
+<p>Ð? каÑ?еÑ?Ñ?ве вÑ?еменного Ñ?еÑ?ениÑ? Ñ?Ñ?ой пÑ?облемÑ? на Ñ?Ñ?звимÑ?Ñ? Ñ?иÑ?Ñ?емаÑ? измениÑ?е вÑ?е
+вÑ?ождениÑ? макÑ?оÑ?а `%m' в smb.conf на `%l' и пеÑ?езапÑ?Ñ?Ñ?иÑ?е Samba.
 
- -<p>This has been fixed in version 2.0.7-3.4, and we recommend that you
- -upgrade your Samba package immediately.
+<p>ЭÑ?а пÑ?облема бÑ?ла иÑ?пÑ?авлена в веÑ?Ñ?ии 2.0.7-3.4, Ñ?екомендÑ?еÑ?Ñ?Ñ? как можно
+Ñ?коÑ?ее обновиÑ?Ñ? пакеÑ? Samba.
 </define-tag>
 
 # do not modify the following line
- --- english/security/2001/dsa-079.wml	2002-02-08 22:27:38.000000000 +0500
+++ russian/security/2001/dsa-079.wml	2016-07-07 17:30:09.296367771 +0500
@@ -1,27 +1,28 @@
- -<define-tag description>uucp uid/gid access</define-tag>
+#use wml::debian::translation-check translation="1.2" maintainer="Lev Lamberov"
+<define-tag description>uucp-доÑ?Ñ?Ñ?п Ñ? Ñ?лагами uid/gid</define-tag>
 <define-tag moreinfo>
- -<p>Zenith Parsec discovered a security hole in Taylor UUCP 1.06.1.  It
- -permits a local user to copy any file to anywhere which is writable by
- -the uucp uid, which effectively means that a local user can completely
- -subvert the UUCP subsystem, including stealing mail, etc.</p>
+<p>Ð?ениÑ? Ð?аÑ?Ñ?ек обнаÑ?Ñ?жил Ñ?Ñ?звимоÑ?Ñ?Ñ? в Taylor UUCP 1.06.1.  Ð?на
+позволÑ?еÑ? локалÑ?номÑ? полÑ?зоваÑ?елÑ? копиÑ?оваÑ?Ñ? лÑ?бой Ñ?айл в лÑ?бое меÑ?Ñ?о, оÑ?кÑ?Ñ?Ñ?ое длÑ? запиÑ?и
+длÑ? полÑ?зоваÑ?елÑ?Ñ?кого иденÑ?иÑ?икаÑ?оÑ?а uucp, Ñ?Ñ?о познаÑ?аеÑ?, Ñ?Ñ?о локалÑ?нÑ?й полÑ?зоваÑ?елÑ? можеÑ?
+полноÑ?Ñ?Ñ?Ñ? подоÑ?ваÑ?Ñ? подÑ?иÑ?Ñ?емÑ? UUCP, вклÑ?Ñ?аÑ? кÑ?ажÑ? поÑ?Ñ?Ñ? и Ñ?. д.</p>
 
- -<p>If a remote user with UUCP access is able to create files on the local
- -system, and can successfully make certain guesses about the local
- -directory structure layout, then the remote user can also subvert the
- -UUCP system.  A default installation of UUCP will permit a remote user
- -to create files on the local system if the UUCP public directory has
- -been created with world write permissions.</p>
+<p>Ð?Ñ?ли Ñ?далÑ?ннÑ?й полÑ?зоваÑ?елÑ?, имеÑ?Ñ?ий UUCP-доÑ?Ñ?Ñ?п к Ñ?иÑ?Ñ?еме, можеÑ? Ñ?оздаÑ?Ñ? Ñ?айлÑ? в
+локалÑ?ной Ñ?иÑ?Ñ?еме, и можеÑ? Ñ?Ñ?пеÑ?но Ñ?гадаÑ?Ñ? локалÑ?нÑ?Ñ? Ñ?Ñ?Ñ?Ñ?кÑ?Ñ?Ñ?Ñ?
+каÑ?алогов, Ñ?о Ñ?далÑ?ннÑ?й полÑ?зоваÑ?елÑ? Ñ?акже можеÑ? подоÑ?ваÑ?Ñ? Ñ?иÑ?Ñ?емÑ?
+UUCP.  Ð?о Ñ?молÑ?аниÑ? UUCP позволÑ?еÑ? Ñ?далÑ?ннÑ?м полÑ?зоваÑ?елÑ?м
+Ñ?оздаваÑ?Ñ? Ñ?айлÑ? в локалÑ?ной Ñ?иÑ?Ñ?еме в Ñ?ом Ñ?лÑ?Ñ?ае, еÑ?ли оÑ?кÑ?Ñ?Ñ?Ñ?й каÑ?алог UUCP
+Ñ?оздан Ñ? пÑ?авами длÑ? запиÑ?и длÑ? вÑ?еÑ? полÑ?зоваÑ?елей.</p>
 
- -<p>Obviously this security hole is serious for anybody who uses UUCP on a
- -multi-user system with untrusted users, or anybody who uses UUCP and
- -permits connections from untrusted remote systems.</p>
+<p>Ð?Ñ?евидно, Ñ?Ñ?а Ñ?Ñ?звимоÑ?Ñ?Ñ? оÑ?енÑ? Ñ?еÑ?Ñ?Ñ?зна длÑ? вÑ?еÑ?, кÑ?о иÑ?полÑ?зÑ?еÑ? UUCP
+в многополÑ?зоваÑ?елÑ?Ñ?киÑ? Ñ?иÑ?Ñ?емаÑ? Ñ? недовеÑ?еннÑ?ми полÑ?зоваÑ?елÑ?ми, или вÑ?еÑ? Ñ?еÑ?, кÑ?о иÑ?полÑ?зÑ?еÑ?
+UUCP и Ñ?азÑ?еÑ?аеÑ? подклÑ?Ñ?ениÑ? Ñ? недовеÑ?еннÑ?Ñ? Ñ?далÑ?ннÑ?Ñ? Ñ?иÑ?Ñ?ем.</p>
 
- -<p>It was thought that this problem has been fixed with DSA 079-1, but
- -that didn't fix all variations of the problem.  The problem is fixed
- -in version 1.06.1-11potato2 of uucp which uses a patch from the
- -upstream author Ian Lance Taylor.</p>
+<p>СÑ?иÑ?алоÑ?Ñ?, Ñ?Ñ?о Ñ?Ñ?а пÑ?облема бÑ?ла иÑ?пÑ?авлена в Ñ?екомендаÑ?ии DSA 079-1, но
+иÑ?пÑ?авление не каÑ?аеÑ?Ñ?Ñ? вÑ?еÑ? возможнÑ?Ñ? Ñ?азновидноÑ?Ñ?ей Ñ?Ñ?ой пÑ?облемÑ?.  Ð?Ñ?облема бÑ?ла иÑ?пÑ?авлена
+в веÑ?Ñ?ии 1.06.1-11potato2 пакеÑ?а uucp, в коÑ?оÑ?ой иÑ?полÑ?зÑ?еÑ?Ñ?Ñ? заплаÑ?а оÑ?
+авÑ?оÑ?а оÑ?новной веÑ?ки Ñ?азÑ?абоÑ?ки Ð?Ñ?на Ð?Ñ?нÑ?а ТÑ?йлоÑ?а.</p>
 
- -<p>We recommend that you upgrade your uucp package immediately.
+<p>РекомендÑ?еÑ?Ñ?Ñ? как можно Ñ?коÑ?ее обновиÑ?Ñ? ппакеÑ? uucp.
 </define-tag>
 
 # do not modify the following line
- --- english/security/2001/dsa-086.wml	2001-11-16 15:54:27.000000000 +0500
+++ russian/security/2001/dsa-086.wml	2016-07-07 17:39:40.489634860 +0500
@@ -1,27 +1,28 @@
- -<define-tag description>remote root exploit</define-tag>
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+<define-tag description>Ñ?далÑ?ннаÑ? Ñ?Ñ?звимоÑ?Ñ?Ñ? Ñ?Ñ?пеÑ?полÑ?зоваÑ?елÑ?</define-tag>
 <define-tag moreinfo>
- -<p>We have received reports that the "SSH CRC-32 compensation attack
- -detector vulnerability" is being actively exploited. This is the same
- -integer type error previously corrected for OpenSSH in DSA-027-1.
- -OpenSSH (the Debian ssh package) was fixed at that time, but
- -ssh-nonfree and ssh-socks were not.</p>
+<p>Ð?Ñ? полÑ?Ñ?или Ñ?ообÑ?ениÑ? о Ñ?ом, Ñ?Ñ?о "Ñ?Ñ?звимоÑ?Ñ?Ñ? компенÑ?аÑ?ионного опÑ?еделиÑ?елÑ? аÑ?ак
+SSH CRC-32" акÑ?ивно иÑ?полÑ?зÑ?еÑ?Ñ?Ñ? злоÑ?мÑ?Ñ?ленниками. ЭÑ?о Ñ?а же оÑ?ибка
+Ñ?ипа Ñ?елÑ?Ñ? Ñ?иÑ?ел, коÑ?оÑ?аÑ? Ñ?анее бÑ?ла иÑ?пÑ?авлена в OpenSSH в Ñ?екомендаÑ?ии DSA-027-1.
+Ð? Ñ?оÑ? Ñ?аз бÑ?л иÑ?пÑ?авлен пакеÑ? OpenSSH (пакеÑ? ssh длÑ? Debian), но
+пакеÑ?Ñ? ssh-nonfree и ssh-socks иÑ?пÑ?авленÑ? не бÑ?ли.</p>
 
- -<p>Though packages in the non-free section of the archive are not
- -officially supported by the Debian project, we are taking the unusual
- -step of releasing updated ssh-nonfree/ssh-socks packages for those
- -users who have not yet migrated to OpenSSH. However, we do recommend
- -that our users migrate to the regularly supported, DFSG-free "ssh"
- -package as soon as possible. ssh 1.2.3-9.3 is the OpenSSH package
- -available in Debian 2.2r4.</p>
+<p>ХоÑ?Ñ? пакеÑ?Ñ? в Ñ?азделе non-free аÑ?Ñ?ива оÑ?иÑ?иалÑ?но не
+поддеÑ?живаÑ?Ñ?Ñ?Ñ? Ð?Ñ?оекÑ?ом Debian, мÑ? вÑ?Ñ? же вÑ?пÑ?Ñ?Ñ?или
+обновлÑ?ннÑ?е пакеÑ?Ñ? ssh-nonfree/ssh-socks длÑ? Ñ?еÑ? полÑ?зоваÑ?елей,
+коÑ?оÑ?Ñ?е еÑ?Ñ? не пеÑ?еÑ?ли на OpenSSH. Тем не менее, Ñ?Ñ?им полÑ?зоваÑ?елÑ?м
+наÑ?Ñ?оÑ?Ñ?елÑ?но Ñ?екомендÑ?еÑ?Ñ?Ñ? пеÑ?ейÑ?и на обÑ?Ñ?нÑ?й поддеÑ?живаемÑ?й пакеÑ? "ssh",
+Ñ?ооÑ?веÑ?Ñ?Ñ?вÑ?Ñ?Ñ?ий Ð?Ñ?иÑ?еÑ?иÑ?м по опÑ?еделениÑ? Ñ?вободного Ð?Ð?. Ð?акеÑ? ssh веÑ?Ñ?ии 1.2.3-9.3
+пÑ?едÑ?Ñ?авлÑ?еÑ? Ñ?обой пакеÑ? OpenSSH, Ñ?Ñ?оÑ? пакеÑ? доÑ?Ñ?Ñ?пен в Debian 2.2r4.</p>
 
- -<p>The fixed ssh-nonfree/ssh-socks packages are available in version
- -1.2.27-6.2 for use with Debian 2.2 (potato) and version 1.2.27-8 for
- -use with the Debian unstable/testing distribution. Note that the new
- -ssh-nonfree/ssh-socks packages remove the setuid bit from the ssh
- -binary, disabling rhosts-rsa authentication. If you need this
- -functionality, run</p>
+<p>Ð?Ñ?пÑ?авленнÑ?е пакеÑ?Ñ? ssh-nonfree/ssh-socks доÑ?Ñ?Ñ?пнÑ? в веÑ?Ñ?ии
+1.2.27-6.2 длÑ? иÑ?полÑ?зованиÑ? в Debian 2.2 (potato) и в веÑ?Ñ?ии 1.2.27-8 длÑ?
+иÑ?полÑ?зованиÑ? Ñ? неÑ?Ñ?абилÑ?нÑ?м/Ñ?еÑ?Ñ?иÑ?Ñ?емÑ?м вÑ?пÑ?Ñ?ком Debian. Ð?амеÑ?Ñ?Ñ?е, Ñ?Ñ?о новÑ?е
+пакеÑ?Ñ? ssh-nonfree/ssh-socks Ñ?далÑ?Ñ?Ñ? Ñ?лаг setuid Ñ? двоиÑ?ного Ñ?айла
+ssh, оÑ?клÑ?Ñ?аÑ? аÑ?Ñ?енÑ?иÑ?икаÑ?иÑ? rhosts-rsa. Ð?Ñ?ли вам нÑ?жна Ñ?Ñ?а
+Ñ?Ñ?нкÑ?ионалÑ?ноÑ?Ñ?Ñ?, запÑ?Ñ?Ñ?иÑ?е</p>
 <p><code>chmod u+s /usr/bin/ssh1</code></p>
- -<p>after installing the new package.</p>
+<p>поÑ?ле Ñ?Ñ?Ñ?ановки нового пакеÑ?а.</p>
 </define-tag>
 
 # do not modify the following line
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXfk2RAAoJEF7nbuICFtKl+dAP/iXK3XE1l117ewyNeCjvna5T
P1NJIpj2zyPYXhzjXs1ly/Ncihv6BSIBmRu3pDEr1zmvUWUkaIK/xYiXXh9n1YwH
oKg3rQIk4Y2QIH3qx3XSARIjsLo/lvAUhtE4pAm/L3MtRnSqOHG5iZsmPS1CF/z3
Ie/9q+xMnEuIUeBJZQkJbzR0HbDVDZb1Bto/3IqHxzUTmYTrmvfpatd2zfyTNH5H
Utj7jPG3EwE+8PQZ8W8JzLk7Q9mfrBi4ODnBdf6FjSkdvQHWJqK/JlYaPEVJOFrF
7V1pYr5fjNsKXH7XHvnShA29PReJd5m9kjbLXj9sYbXCek80sPh65Du7HVuXJQJp
+dVV1e3zbaSppaMlqJG/+ZbG9g63wCiCla28v4dBnShIFwUgAZERaiPrykAoYc/r
n3M+oPUvam6jwvEb3jogqMG8TgLuMlKsmLZQliM/krKVTdqBpHgME80zQ0VjuJUz
TSfdjYrLumNsFoVFAwz4FPDQ0Ctrn/IU7Du6aa+fsINH9uqEflpNK5VFV8S0RXlY
Ty2m/++nasH0bgH758hqoLFbh9gljWqmf/2PTey+qXIH1bn4dI1v0UVItQhIvidR
j4anbSA4hb7BjfQoA+NBLrYqS8MZp+N7nF+RFsCvQosIQK0qiwEr/dDg+CGYChp6
em/AOpkvIJqTrxL8K0B7
=fyMO
-----END PGP SIGNATURE-----
Reply to: