openSUSE Security November 2007

security@lists.opensuse.org

46 participants
24 discussions

[opensuse-security] ssh-ing to an old suse.

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have an old computer with suse 7.3 on it (the latest it can use: it is a pentium classic with 32 MB). I used the other day to ssh to my main computer (opensuse 10.3) and kill a process that had locked the keyboard). It has it's small uses. Today I tried to ssh to it, and i can't: the ssh session stays for ever like this: cer@nimrodel:~> ssh telperion.valinor never asking for the password. What is going on? It worked with 10.2, I think. I know it is not a network issue. It may be related to an authentication method that has changed defaults in 10.3, but I don't know what exactly. There is no entry in the logs. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHQZUDtTMYHG2NR9URAlG7AJ4pLwjrRwgeT/pzMrCNOabhhfSz8QCbB1NM AAjxA7IdKLe3VV6owEpKlKA= =a/67 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 6 months

[opensuse-security] Encripted filesystem write blocks the system (10.3)

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have an encripted filesystem inherited from 10.2 and before. I have this line in fstab: /biggy/crypta_f.mm.x /mnt/crypta.mm.x xfs noauto,user,noatime,nodiratime,loop,encryption=twofish256 1 4 Reading from this filesystem works (I'm copying it elsewhere now). Writing to this filesystem, from another similarly encripted filesystem, large files (between 300 and 400 MB), locks the console where the copy is having place. The copy process stops. It is unkillable. Umount of that filesystem locks (and umount is unkillable). Reboot filesystem locks. If I try to "ls -l" the destination dir of the copy (that is locked, frozen) also freezes. I have to lazy umount ("umount -l /mountpoints &") all the mountpoints I can, and then try to reboot (which hangs) and then poweroff the machine forcefully. There is absolutely nothing in the logs relative to this problem (I know how to look into logs). I have fsck the filesystem, nothing: nimrodel:~ # losetup -e twofish256 /dev/loop2 /biggy/crypta_f.mm.x Password: nimrodel:~ # file -s /dev/loop2 /dev/loop2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) nimrodel:~ # xfs_check /dev/loop2 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. nimrodel:~ # mount /dev/loop2 /mnt/crypta.mm.x/ nimrodel:~ # umount /dev/loop2 nimrodel:~ # xfs_check /dev/loop2 nimrodel:~ # No errors. I'm aware that the encription filesystems have changed in 10.3, but the only document I have is the release notes. Probably I would have to use a different method than losetup, but I have no idea which. An encripted filesystem I see it uses devmap. But notice that the problem arises from a filesystem mounted directly from fstab - shouldn't this method be used now anymore? In any case, the "classic" method should freeze the computer, as it does :-? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHTiu2tTMYHG2NR9URAr5gAJwNybIdLLBs5NTiirEehsYUOUzKOwCeN0s3 +FOv7HWC2FOfojUrCKae3r4= =WgTn -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 6 months

[opensuse-security] LUKS and its master key

by Jochen+opensuse-security＠Hayek.name

I found LUKS recently through SUSE Linux 10.3, and the other night a read an article in c't 2006/11. I can't seriously appreciate the technical internals, as I'm not too compentent there. Anyway: Kudos to Clemens Fruhwirth! But I am not really sure, whether I can trust, what I read in that article regarding the master key, spefically that the master key can be read from the LUKS volume by the sys admin without any difficulties. Does that really mean, that as soon as somebody gains control over my computer with a mounted LUKS encrypted (external) disc and he also manages to gain root priviliges, that he can retrieve the necessary information, to mount that disc himself with LUKS-means again?!? I mean without me passing the keys to him. If that is seriously so, I think I will have to find myself another disc encryption toolset, as I cannot tolerate, that intruders can deal with my personal data without my explicit permission and support. Whether those intruders have governmental permissions, I don't f...ing care. I appreciate your serious comments. J. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 6 months

[opensuse-security] Treason uncloaked

by Magnus Rosenbaum

Hello everybody, yesterday one of my webservers refused to deliver any more webpages, while reaching the server with ssh was fine and the load of the server was very low. But there were 100 apache processes, which is the configured limit on that server. Usually there are about 30 apache processes. In /var/log/messages I found some messages like this at the same time: Nov 19 14:38:12 server1 kernel: TCP: Treason uncloaked! Peer 87.160.97.54:2560/80 shrinks window 1710186274:17 10191335. Repaired. Does anyone know what this means and how it might be related to the apache processes? Ist this some kind of DoS attack? cu, Magnus -- Carl Magnus Rosenbaum M.A. Administration - Programmierung - Weiterbildung http://cmr.cx/ Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662 PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

14 years, 7 months

[opensuse-security] How does one convert from /etc/cryptotab to /etc/crypttab

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, According to the release notes, I thought that /etc/cryptotab was to be converted to /etc/crypttab while upgrading 10.2 to 10.3, but it wasn't. How do I do it? The entry in /etc/cryptotab is this: /dev/loop0 /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 /cripta xfs twofish256 noatime,nodiratime I see a man page for crypttab, which says that the lines should be: <target device> <source device> <key file> <options> But I don't see clearly. It says: · The first column, target device specifies the mapped device name. It must be a plain filename without any directories. A mapped device /dev/mapper/device name will be created by cryptsetup(8) crypting data from and onto the source device. To actually mount that device it needs to be listed in /etc/fstab. Ie, is it an invented name? A non existing name in /dev/mapper/? Like /dev/mapper/MyCrypto? Then the line would be: MyCrypto /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 .... Now, third field: · The third column key file specifies the file to use for decrypting the encrypted data of the source device. It can also be a device name (e.g. /dev/urandom, which is useful for encrypted swap devices). Warning: luks does not support infinite streams (like /dev/urandom), it requires a fixed size key. Are they talking of the mount point? A file containing the passphrase? I believe the second. · The fourth field options specifies the cryptsetup options associated with the encryption process. At minimum, the field should contain the string luks or the cipher, hash and size options. Options have to be specified in the format: key=value[,key=value ...] Cipher, hash, size.... I have no idea how to relate this to the original remaining options: ... xfs twofish256 noatime,nodiratime Is this suppossed to be this way? I don't see how... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHTi9/tTMYHG2NR9URAtJ8AJ9+7Cm5VwCEh/PTE93iKzTJh+a1+ACfdB6q yEAJUTkmAeAg4EBsAEDXDRA= =YGOD -----END PGP SIGNATURE-----

14 years, 7 months

[opensuse-security] +unsubscribe

by Frank Dingeldein

+unsubscribe _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 7 months

Re: [opensuse-security] Encripted filesystem write blocks the system (10.3)

by Paco Cruz

Hola Carlos On 30/11/2007, Carlos E. R. <robin.listas(a)telefonica.net> wrote: > > That's very nice - at least for the people creating new encrypted > filesystems. Mine are older, some created for SuSE 9.2, maybe before. > Those on the hard disk I can recreate, and probably I will; but those in > DVD I can't. In my fstab I already have 4 (four) different entries to > mount DVDs created using 4 different methods over time. > > Now I guess I have to create a new '5' method for DVDs using LUKS, which I > hope will last longer, as the options are written inside somehow :-) > > Don't you think that it would be more convenient (and a lot of less troublesome) to copy all those four DVDs to new ones encrypted with LUKS? Do you have to access them through a disparate number of systems? You could set up a proxy to access the new LUKS-encrypted ones. Just my two cents :-) -- Saludos Paco Cruz --------------------------------------------------------------------- If you think that training is expensive and complicated, try ignorance instead. Roy Crock (founder of McDonalds) Si crees que el aprendizaje es caro y complicado, prueba con la ignorancia. --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 7 months

[opensuse-security] Automatic update silently broken after removing zmd-updater, zen, and rug (OpenSUSE 10.2)

by Sven.Hartrumpf＠FernUni-Hagen.de

Hello everyone. Automatic weekly updates stopped working after I did a rpm -e zmd-updater zen rug for OpenSUSE 10.2 machines. If this is my fault, configuring (again) automatic update in yast should warn me that automatic updates will not work. Greetings Sven

14 years, 7 months

[opensuse-security] Where is snort?

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is no snort in 10.3. Why? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHSg8ItTMYHG2NR9URAmbIAJ4/XfzorMHrTclNlUpf1g+WC3k9fACfWbRW 8/8bLrVwfLyYbiqZW/InBBs= =KMUJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 7 months

[opensuse-security] What's the matter with the updates?

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 YOU says it wants to update: bug-buddy java-1_5_0-sun java-1_6_0-sun updates-alternatives Knowing about last Friday problem, I'm suspicious - and yes, there are conflicts again: #### YaST2 conflicts list - generated 2007-11-20 01:20:48 #### Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin A conflict over java-1.3.1-plugin (java-1.3.1-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5) sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64) findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find) === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5) (null) Conflict Resolution: ( ) do not install java-1_6_0-sun-plugin ( ) do not install java-1_5_0-sun-plugin (X) Ignore this conflict of java-1_6_0-sun-plugin atom:bug-buddy cannot be installed due to missing dependencies There are no installable providers of bug-buddy >= 2.20.1-1.1 for atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] === atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] === atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] is needed by patch:bug-buddy-4686-0.noarch[gwdg-update] (bug-buddy == 2.20.1-1.1) bug-buddy-2.20.1-1.1.i586[gwdg-update] provides bug-buddy == 2.20.1-1.1, but it is uninstallable. Try installing it on its own for more details. (null) Conflict Resolution: (X) do not install bug-buddy ( ) Ignore this requirement just here #### YaST2 conflicts list END ### And I try again, and I get the same conflict with a different text, impossible to understand unless you are a Yast programmer :-( #### YaST2 conflicts list - generated 2007-11-20 01:23:12 #### Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin A conflict over java-1.4.2-plugin (java-1.4.2-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5) sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64) findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find) === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5) (null) Conflict Resolution: ( ) do not install java-1_6_0-sun-plugin ( ) do not install java-1_5_0-sun-plugin (X) Ignore this conflict of java-1_6_0-sun-plugin patch:bug-buddy cannot be installed due to missing dependencies There are no installable providers of bug-buddy == 2.20.1-1.1 for patch:bug-buddy-4686-0.noarch[gwdg-update] === patch:bug-buddy-4686-0.noarch[gwdg-update] === patch:bug-buddy-4686-0.noarch[gwdg-update] will be installed by another application. (ApplLow/ApplHigh) atom:bug-buddy-2.20.1-1.1.x86_64[gwdg-update] is needed by patch:bug-buddy-4686-0.noarch[gwdg-update] (bug-buddy == 2.20.1-1.1) atom:bug-buddy-2.20.1-1.1.ppc[gwdg-update] is needed by patch:bug-buddy-4686-0.noarch[gwdg-update] (bug-buddy == 2.20.1-1.1) atom:bug-buddy-2.20.1-1.1.i586[gwdg-update] provides bug-buddy == 2.20.1-1.1, but it is locked. (null) Conflict Resolution: ( ) unlock bug-buddy ( ) unlock all resolvables (X) do not install bug-buddy ( ) Ignore this requirement just here #### YaST2 conflicts list END ### So I answer the same thing as before, and get a third conflict: #### YaST2 conflicts list - generated 2007-11-20 01:25:45 #### Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin A conflict over java-1.4.1-plugin (java-1.4.1-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5) sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64) findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find) === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5) (null) Conflict Resolution: ( ) do not install java-1_6_0-sun-plugin ( ) do not install java-1_5_0-sun-plugin (X) Ignore this conflict of java-1_6_0-sun-plugin #### YaST2 conflicts list END ### I get the same, and I answer the same: #### YaST2 conflicts list - generated 2007-11-20 01:26:40 #### Cannot install java-1_6_0-sun-plugin, because it is conflicting with java-1_5_0-sun-plugin A conflict over java-1.4.0-plugin (java-1.4.0-plugin) requires the removal of java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] which is scheduled for installation === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] === java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] is needed by atom:java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (java-1_6_0-sun-plugin >= 1.6.0.u3-0.5) sed-4.1.5-64.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (sed == 4.1.5-64) findutils-4.2.31-24.i586 is needed by java-1_6_0-sun-plugin-1.6.0.u3-0.5.i586[gwdg-update] (/usr/bin/find) === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] === java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] is needed by atom:java-1_5_0-sun-plugin-1.5.0_update13-0.5.i586[gwdg-update] (java-1_5_0-sun-plugin >= 1.5.0_update13-0.5) (null) Conflict Resolution: ( ) do not install java-1_6_0-sun-plugin ( ) do not install java-1_5_0-sun-plugin ( ) Ignore this conflict of java-1_6_0-sun-plugin #### YaST2 conflicts list END ### So, a third time I say to ignore, and this time it shuts up. Why is this nonsense? I should install both 1_5 and 1_6 patches: cer@nimrodel:~/.ssh> rpm -q java-1_6_0-sun-plugin java-1_5_0-sun-plugin java-1_6_0-sun-plugin-1.6.0.u3-0.3 java-1_5_0-sun-plugin-1.5.0_update13-0.3 but yast complains about conflicts, even if the initial screen says there are patches for both that I should apply. What is this all about? Finally, it says it is going to install: java-1_5_0-sun java-1_5_0-sun-plugin java-1_6_0-sun java-1_6_0-sun-alsa java-1_6_0-sun-jdbc java-1_6_0-sun-plugin updates-alternatives - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFHQiuttTMYHG2NR9URAmCAAJoDgnwczaRlojPnITiJwaQ1eTfZwQCfdDlH FjreVByN6egkwUjcjCI4hBE= =U8/O -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-security+help(a)opensuse.org

14 years, 7 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

openSUSE Security November 2007