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
Apr 20 16:15:18 megara kernel: Keyboard timeout
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.
The mouse said,"can i take the day off?" and the lion responded "No, for
you will be my after lunch snack" <crunch> - Anonymous
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
----/ / _ Fred A. Miller
---/ / (_)__ __ ____ __ Systems Administrator
--/ /__/ / _ \/ // /\ \/ / Cornell Univ. Press Services
-/____/_/_//_/\_,_/ /_/\_\ fm(a)cupserv.org
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
Any help on this would be much appreciated.
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 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 :).
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 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 so weak. If you can
give any suggestions or feedback, an e-mail would be appreciated.
-- Bryan Hughes
> 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
>> 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 :(
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
Sorry, I forgot the mailing-list
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
The home page is
There is a newer version available but I has not yet used it.
This need detailed configuration ...
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.
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
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?
b&b computersysteme * kämperheide 10 * 58285 gevelsberg * germany
fon +49 2333 913924 * fax +49 2333 913925 * http://www.bbcomp.de
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! ;)
Peter Münster **** Brittany **** France