similar to: program xxx is not vulnerable.

Hi, FYI - don't sue me for posting this here - I know, everyone who needs this info *should* have it already, but maybe not ;-) Kind regards, B. Courtin -- OpenSSL Security Advisory [30 July 2002] This advisory consists of two independent advisories, merged, and is an official OpenSSL advisory. Advisory 1 ========== A.L. Digital Ltd and The Bunker (http://www.thebunker.net/) are

I picked up the following from Bugtraq. -----Forwarded message from David Phillips <phillips@PCISYS.NET>----- MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <01BC5D8D.679DD4A0@frank56.pcisys.net> Date: Sat, 10 May 1997 21:56:05 -0600 Reply-To: David Phillips <phillips@PCISYS.NET> Sender: Bugtraq List

I seem to have stumbled across another vulnerability in DIP. It appears to allow any user to gain control of arbitrary devices in /dev. For instance, I have successfully stolen keystrokes from a root login as follows... (I could also dump characters to the root console) $ whoami cesaro $ cat < /dev/tty1 <------ root login here bash: /dev/tty1: Permission denied

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: remote root exploit (SITE EXEC) fixed Advisory ID: RHSA-2000:039-02 Issue date: 2000-06-23 Updated on: 2000-06-23 Product: Red Hat Linux Keywords: wu-ftpd, root exploit, site exec, buffer overrun Cross references: N/A

SSH.COM says their SSH2 is not vulnerable to the ZLIB problem even though they use the library (details below). Can OpenSSH say the same thing? In either case, it seems like there ought to be an openssh-unix-announce message about what the situation is. I may have missed it, but I don't believe there was one. Yes, openssh doesn't have its own copy of zlib source but it would still be

Summary: you can exploit a single-byte buffer overrun to gain root privs. When, half a day after releasing version 2.2beta37 of the Linux nfs server, I received a message from Larry Doolittle telling me that it was still vulnerable to the root exploit posted to bugtraq, I was ready to quit hacking and start as a carpenter... Tempting as that was, I didn''t, and started looking for the

-----BEGIN PGP SIGNED MESSAGE----- - --------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: Buffer overflow problem in the inews program Advisory ID: RHSA-1999:033-01 Issue date: 1999-09-01 Keywords: inn inews buffer overflow - --------------------------------------------------------------------- 1. Topic: New packages for INN

The instructions in RHSA-2000:037-01 (2.2.16 kernel update) tell you: 4. Solution: For each RPM for your particular architecture, run: rpm -Fvh [filename] where filename is the name of the RPM. These instructions are incomplete and may result in a system that is unbootable. After updating the RPM files, you should also: (1) run mkinitrd to create a new initial ramdisk image

hi ppl, well, here is another standard buffer overrun vulnerability, which may sometimes lead to root compromise (not always. not in new distributions, fortunately). Current Slackware and current RedHat don''t install minicom suid root, only sgid/uucp, which is not *that* dangerous. But when you build minicom from source, it asks you to do "chmod +s" on it. Summary:

Hello... I am a student at G?teborgs university who is the system adminstrator in one of the student clubs here. We run about 10 computers with one server. Mainly linux and all run openssh. We have closed telnet so only ssh-connections is allowed. Last night i got a mail from one of the system adminstrators at G?teborgs university saying that there was a possible root exploit in all openssh

Are there any known vulnerabilities in portmap (redhat''s portmap-4.0-7b)? I''ve been receiving a lot of attempts to access the portmap port on some linuxppc machines I administer by various machines which clearly have no business with mine, and I wonder if this is an attempt to break in to my machines. I''ve searched some archives, but I haven''t yet found any

Hello, Anyone have information on whether RedHat-5.0+ is affected by the recent (today's) CERT advisory regarding QPOP? thanks, -bp -- B. James Phillippe <bryan@terran.org> Linux Software Engineer, WGT Inc. http://earth.terran.org/~bryan

In Debian 1.1, the optional DOSEMU package installs /usr/sbin/dos setuid root. This is a serious security hole which can be exploited to gain access to any file on the system. Package: dosemu Version: 0.64.0.2-9 ------- start of cut text -------------- $ cat /etc/debian_version 1.1 $ id uid=xxxx(quinlan) gid=xxxx(quinlan) groups=xxxx(quinlan),20(dialout),24(cdrom) [quinlan:~]$ ls -al

Matt <panzer@dhp.com> writes: > This came from the linux-server list. But reminded me of a something I > wanted to know about. Is there a standard for people to syslog possible > security violations? This would make it easier to find them in huge log > files with swatch or other monitoring tools. Security-related log entries don''t have their own

I'm right now handling this beach-ball sized grenade, and trying to figure out which of our services need to be locked down right away. Since dovecot passes values via environment variables based on user input (e.g. username, password, mailbox?) to auxilliary executables (including possibly bash shell scripts), is dovecot vulnerable to this exploit? (This is not a fault of dovecot, but

CORE SDI http://www.core-sdi.com SSH1 CRC-32 compensation attack detector vulnerability Date Published: 2001-02-08 Advisory ID: CORE-20010207 Bugtraq ID: 2347 CVE CAN: CAN-2001-0144 Title: SSH1 CRC-32 compensation attack detector vulnerability Class: Boundary Error Condition Remotely Exploitable: Yes Locally Exploitable: Yes Release Mode:

According to the vulnerability test script from shellshocker.net, the latest bash versions on CentOS5 and CentOS6, 3.2-33.el5_11.4 and 4.1.2-15.el6_5.2, resp., are still vulnerable to CVE-2014-6277. In fact, on CentOS6, abrtd will send you a nice report about it. Does anyone know if upstream is working on a fix? [root at host ~]# bash ~/shellshock_test.sh CVE-2014-6271 (original shellshock):

-| == Marcin Bohosiewicz marcus@venus.wis.pk.edu.pl == |- -| == tel. +048 (0-12) 37-44-99 marcus@krakow.linux.org.pl == |- -| == Strona Domowa - http://venus.wis.pk.edu.pl/marcus/ == |- ---------- Forwarded message ---------- Date: Sat, 26 Apr 1997 16:16:05 -0400 From: George Staikos <staikos@0WNED.ORG> Approved: R.E.Wolff@BitWizard.nl To: BUGTRAQ@NETSPACE.ORG Subject:

Introduction. ------------ Every now and then a new "exploit" turns up of some program that uses tmp files. The first solution was "sticky bits", but since links exist (that''s a LONG time), that solution is inadequate. Discussion. ---------- The problem is that you put an object (link/pipe) in the place where you expect a program to put its tempfile, and wait for

Alexander O. Yuriev wrote: > > Your message dated: Wed, 20 Nov 1996 18:04:39 EST > > >has anyone played with the securelevel variable in the kernel and the > > >immutable flags in the ext2 file system? > > > > Yes, and its actualy quite nice. > > > > >The sysctrl code seems to allow the setting of the flag > > >only by init (PID=1)