OpenBSD Journal

Learning about stack based kernel overflows, and OpenBSD

Contributed by jose on from the more-instruction dept.

rik writes: "Kris Vangeneugden has written a GCIH paper on OpenBSD Privilege Escalation. It references Guninski's advisory from 2003. The paper can be found at "

(Comments are closed)

  1. By Dunceor () on

    nice live example and got analysis of the vuln/exploit..

  2. By Helevius () on


    This is not a troll question -- I would like some expert commentary on a Slashdot post about the latest OpenBSD issue. This comment says:

    "There have actually been a number of local and remote root holes in the default install of OpenBSD during that time frame..the only sense in which their claim is true is that they don't count root holes except in the head of the CVS tree. If a release from a year ago had the hole, but the current tree does not, they don't count it.

    For example, a couple of years ago there was a telnetd exploit discovered after OpenBSD had disabled telnetd by default in OpenBSD-current, but a recent prior release had shipped with telnetd enabled. That allowed them to rationalize not counting it as a remote hole. There are a number of other similar examples."

    Can someone elaborate on this or refute it?

    Thank you,


    1. By Josh () on

      Thats BS. OpenBSD maintains a -stable branch in the CVS Repository for one year. Each release is maintained for exactly one year...with a formal release being made every 6 months. That means right now, 3.3 -stable is available in CVS. After the one year mark, your on your own in regards to patches, etc.

      Not only are major problems fixed in -stable, but also minor one's as well...

      See for more information.

    2. By Daniel Hartmeier () on

      I assume the reference is to the teso telnetd advisory, which was published Jul 18 2001.

      Check cvsweb. OpenBSD was at 2.9-current at that time (2.9 the most recent release).

      telnetd was disabled in /etc/inetd.conf r1.32, on Sep 26 1999, the last release with telnetd enabled was 2.5, from April 1999.

      So, not exactly a "recent prior release", but rather a more than two years older, unsupported release.

      So, yes, if you find a remote exploit NOW that works only against 2.x-release, I guess the counter on the web site wouldn't be increased. Even if the hole WAS present when that 2.x was released, and MIGHT have been known ever since then.

      Does that definition of the counter make the statement significantly less strong for the typical user, who updates once a year and doesn't run unsupported releases?

      I guess if you want a counter increment as a trophy, you'll have to accept how it is defined, and find a bug in recent code. It's not redefined arbitrarily, the sshd hole incremented it, after all.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]