openSUSE Security April 2000

security@lists.opensuse.org

81 participants
100 discussions

by Jae

sorry for posting here, but i'm hoping someone may have an idea and point me in the right direction. every so often i get these errors in my syslog : Apr 20 16:03:03 megara kernel: Keyboard timeout[2] Apr 20 16:15:18 megara kernel: Keyboard timeout[2] the keyboard hangs right before they occur - they seem to be random and sometimes frequent. i notice this on my system here and at home - both running 6.3. any ideas? thanks -Jae ** The mouse said,"can i take the day off?" and the lion responded "No, for you will be my after lunch snack" <crunch> - Anonymous

22 years, 3 months

XFree86 xkbmap parameter buffer overflow

by Fred A. Miller

XFree86 xkbmap parameter buffer overflow XFree86 versions 3.3.5 and 3.3.6 have been found to contain a buffer overflow in the xkbmap command-line switch. An attacker can execute arbitrary code as root, since XFree86 runs either with setuid permissions, or via a wrapper that is setuid. No patches have been made available. Version 4.0.0 is reported to be fixed. Source: Bugtraq http://archives.neohapsis.com/archives/bugtraq/2000-04/0076.html -- ----/ / _ Fred A. Miller ---/ / (_)__ __ ____ __ Systems Administrator --/ /__/ / _ \/ // /\ \/ / Cornell Univ. Press Services -/____/_/_//_/\_,_/ /_/\_\ fm(a)cupserv.org

22 years, 3 months

/usr/include/netinet/ip_udp.h

by Santoyo, Javier

Hello I'm running SuSe 6.3 and I am trying to compile some .c code. I am missing the /usr/include/ip_udp.h file does anyone know where I can find this for SuSe 6.3? Any help on this would be much appreciated. Thank you, Javier

22 years, 3 months

possible security problem with weak perms on /dev/fd[01] in suse 6.3 distro

by techno＠crosslink.net

Hi. I thought I would notify you of my findings on a possible security problem within suse 6.3. Below is an excerpt about /dev/fd[01] permissions that I wrote a few days ago. I'm not sure if this has been noticed before. If not, I hope the information does you some good. I'd appreciate any responses on the matter that you can give, thanks :). [cut] Out of the box, SuSE 6.3 allows global rw access on the primary and secondary floppy drive (/dev/fd0 and /dev/fd1). Because devices can be written to directly, just like anything else, the floppy drives do not need to be mounted for any user to write data to a disk that has been left in the drive. Depending on the systems setup, this can be a very malicious tool. If the system boots SuSE directly from a floppy disk, chances are the disk is left in the drive while the system is up. If a user were to log on, and decide to use 'dd' (amongst a variety of other tools, or even just a 'cat FILE > /dev/fd0') the boot floppy would be ruined. A lazy sysadmin who didn't check the logs would not see that the bootdisk had been ruined, and upon reboot, may find himself with a dead box until the disk can be replaced. This is just one scenario where the weak perms on the devices can be dangerous. I just recently noticed this after installing SuSE 6.3 on one of my systems over a month ago. The permissions on /dev/fd[01] have been checked on several SuSE 6.3 systems and all check out as o+rw. If you are running SuSE 6.3 and have users other than yourself logging in, your best bet is to 'chmod o-rw /dev/fd0'. I cannot think of one good reason why SuSE would have set permissions on /dev/fd[01] so weak. If you can give any suggestions or feedback, an e-mail would be appreciated. -- Bryan Hughes init(a)crashdot.org

22 years, 3 months

Re: [suse-security] imapd4r1 v12.264 and Security Implications

by marc＠suse.de

Hi > The following was posted on FreeBSD-Security today. I was interested > in the official SuSE position since I run both OS's. here it is: >> I consider the post by the vendor in the bugtraq forum to be some sort of >> poor joke. At this point, it would appear that anyone who takes security >> seriously should use some other mail package, or risk their systems' >> integrity. In particular, the thing about chroot'ing to /tmp is fairly >> laughable. While partitioning can be a useful scheme for reducing risk, >> "/tmp" is not the place to chroot to, and chroot'ing is not a replacement >> for careful code auditing. The suggestion that stackguard should be >> required to make their software secure has wandered far beyond >> ``questionable,'' and well into the ``don't touch anything related to my >> system ever again.'' although the language is a bit rude, he is absolutely correct. >> The University of Washington IMAP programmers have proven time and again >> that they are quite capable of releasing code that puts people's system's >> at risk. They also are reluctant to admit or fix the bugs, and have >> demonstrated poor understanding of systems security issues. In other >> words, they make the poorest of choices when it comes to selecting >> developers for security-sensitive software (i.e., remote mail access >> servers). Perhaps we should fedex the uw-imapd people to the OpenBSD camp >> for correctional treatment. well ... it's not the first vulnerability in wu-imap. and the response of the wu-imap programmer really shows that he does not know about secure coding. a security audit of the code would really be needed, however, after half a year new vulnerabilities would be there and the thing would start over. >> Given that attitude of the developer, I would strongly recommend we mark >> the port as FORBIDDEN, and would also seriously consider an suggestion to >> simply drop it from the ports and packages collections. this is unrealistic. people want and some even depend on imapd. and if we would do that to imapd, we would have to do the same for pop3, ftp etc. so the solution is to switch to a imapd with more knowlegable programmers. not a very easy task ... we will provide an update for wu-imapd. but we propose the use another imapd. as far as I remember, there is another imapd server on the SuSE CDs (there are far too much packages to remember them all ;-))). Let's hope that the code of that one is better ... well, time to do a sourcecode audit :( *sigh* Greets, Marc -- Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: marc(a)suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka" Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9 70 D4 87 B5 63 6C

22 years, 3 months

FW: [suse-security] imapd4r1 v12.264 and Security Implications

by Freudenberger Joerg

Sorry, I forgot the mailing-list -----Original Message----- [...] Have also a look for lclint on SuSE 6.3 as lclint-2.2a-94 on SuSE 6.4 as lclint-2.2a-136 I had spectecular success without configuring useing this version some years ago. I'm afraid, the output is only readable for real experienced programmers. The home page is http://www.sds.lcs.mit.edu/lclint/index.html There is a newer version available but I has not yet used it. This need detailed configuration ... yours Jörg

22 years, 3 months

Root setuid files in /usr/lib/cdb

by europax＠home.com

Hello all, I am in the process of hardening my cable-modem connected SuSE system. I was searching for root owned Setuid files, and came across hundreds in the /usr/lib/cdb directory. What are these files for exactly? Do they really need to be Setuid?. Thanks, Rob.

22 years, 3 months

syslog doesn't log after rotation

by Michael Balzer

dear suse security team, on my standard suse 6.3 internet server, i have to do "/sbin/init.d/syslog reload" after any log rotation. if i don't restart it, syslog will not write to the new log files. this is a security issue, as i cannot track security problems without log entries. i already sent this as a bug report to suse a long time ago but never got any response. what can i do? regards, michael balzer -- b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de

22 years, 3 months

passwords limited 8 characters

by Ertan Sekmen

hello, is there any probram come with suse 6.3 to allow users have password more than 8 characters, or do i need to compile ? Is this called md5, ?

22 years, 3 months

mouse permissions

by Peter Münster

Hello, on SuSE 5.3 /dev/psaux (PS2-mouse) was read and write for all users, now (with SuSE >= 6.2) it's read only (perms = 664). Is there any risk, to enable write permissions again on this device? (quake needs it! ;) Cheers, Peter -- Peter Münster **** Brittany **** France URL: http://gmv.spm.univ-rennes1.fr/~peter/

22 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 April 2000