Contributed by jose on from the more-invalid-arguments dept.
For OpenBSD 3.3, Patch 013 addresses this issue.
UPDATE: Read on for the security-announce mail.
Date: Sat, 22 Nov 2003 15:36:16 -0700 From: Todd C. MillerTo: security-announce@OpenBSD.org Subject: two localhost panics Two localhost panics were recently fixed in the OpenBSD source tree. We do not believe these can be used to escalate privileges but they can be used to crash a machine given local access. The first bug involves an unsigned integer wraparound in uvm_vslock() and uvm_vsunlock() that can be triggered by passing the sysctl() function certain arguments. Fixes have been committed to the 3.3 and 3.4 -stable cvs branches, and patches are also available at: ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/3.4/common/007_uvm.patch and ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/3.3/common/012_uvm.patch The second bug was due to an incorrect bounds check in the semop() and semctl() functions that can be triggered by passing certain arguments to these functions when the kern.seminfo.semmni sysctl value is less than the value of kern.seminfo.semmsl (this is the case for the default settings). Fixes have been committed to the 3.3 and 3.4 -stable cvs branches, and patches are also available at: ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/3.4/common/008_sem.patch and ftp://ftp.OpenBSD.org/pub/OpenBSD/patches/3.3/common/013_sem.patch Alternately, a workaround is to set kern.seminfo.semmni equal to kern.seminfo.semmsl, e.g. sysctl -w kern.seminfo.semmni=`sysctl -n kern.seminfo.semmsl`
(Comments are closed)
By Dunceor () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Darn! You beat me to the de rigueur uBSD posting!
By Wouter () on
Comments
By SH () on
By Anonymous Coward () on
There's no relationship between the number of bugs found in a period of time, and the quality of the code. Or at least not always ;)
Comments
By Anonymous Coward () on
Comments
By SH () on
Comments
By Anonymous Coward () on
AND YOU WANT ME TO TREAT YOU SPECIAL??????
hahaha he's dying right now
MORE BUGS FOR THEO
Comments
By rankor_industries () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Comments
By bumby () on
just leave the trolls alone, they are not worth the time anyways...
Comments
By Anonymous Coward () on
Comments
By bumby () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
By bumby () on
What I wanted to have said, was that I thought it was, and is, rather useless to be calling people retards back and forth, even though the poster has a point in his/her comment.
Of course, posting a comment about it, with no further "usefullnes" for the parent posts obviusly didn't do any good.
So I guess I was hoisted by my own petard.
And to answer your question, even though you surely know the answer for it:
Assumed the page you want to mprotect is first mmaped you'll get yourself a rwx:ed stackpage, which I guess would later be used to execute code from, probably placed there from an overflowed buffer.
But what do I know, I'm not as 1337 as you are.
Your point was?
Comments
By Anonymous Coward () on
Taking a look at this might help:
http://www.openbsd.org/papers/pacsec03/e/mgp00010.html
You get an rwx'd stackpage, and everything else becomes rwx as well (data, bss, heap..etc). And when it happens, you'll never know. Sleep soundly my OpenBSD friends!
Ask your OpenBSD developers why they never told you about this. Ask them why they failed to mention when they said that W^X doesn't break anything, why XFree86 modules do not work.
Comments
By Anonymous Coward () on
Comments
By krh () on
> nested functions
> never happen in real life.
There you go! Much better now.
> Thank you.
You're welcome.
Comments
By Anonymous Coward () on
By bumby () on
"Ask your OpenBSD developers why they never told you about this."
Why should I even try to accuse them for anything? They are spending their time to create a product which they give a away for free, and they even give me the source for it, for me to do whatever I want with. I think they are doing a great job, and I love their product. Of course it has bugs, most code have. And I'm sure they do what is in their power to fix these bugs.
Now, if you are so much better, why don't you help fixing it?
You see, the beauty in it is that I don't need to know the answer to your question to use openbsd. Of course, I wouldn't mind having the knowladge you have since I could then fix such stuff myself. We all spend our time on different things, and we all enjoy different things. I'm greatfull that there are people like you, who enjoy spending their time fixing these bugs, so people like me, who enjoy other things can spend time on those.
Have a nice day.
Comments
By Anonymous Coward () on
By Anonymous Coward () on
Comments
By Anonymous Coward () on
Do you think that openbsd with it's limited developper base and almost non-contributing users has the same resources as the linux-scene? Openbsd does quite well at the moment, and if they weren't around for the last 7 years or so, security in general unices would still be in it's infancy...
Comments
By Anonymous Coward () on
you have got to be kidding me...
like to provide some proof of how without openbsd for the last 7 years, linux would be in security infancy?
the only thing openbsd has come up with themselves is strlcpy, and no one in linux gives a shit about it (as well they shouldn't)
i'd like to hear your reasons, really. excuse my laughter.
Comments
By krh () on
Comments
By Anonymous Coward () on
By Anonymous Coward () on
By Anonymous Coward () on
Dear god. Must every one of your 4 IP based alter-egos _always_ have to come back to a PAX related vendetta? Have you _really_ nothing better do with your time?
By Dunceor () on
Comments
By Anonymous Coward () on
By Anonymous Coward () on
Comments
By Sam () on
You clearly don't.
Comments
By Anonymous Coward () on
Comments
By SH () on
Coming from someone running Windows XP, I think I'll be less than insulted. It also doesn't change that the original poster is correct, but because he doesn't subscribe to your groupthink, he must be a "troll." Quick, someone say he's say spreading FUD, that's always a good way to disagree with someone without providing any supporting evidence!
You and the original poster beeing one and the same? Your contribution here is just immature pissing in other peoples forum.
Comments
By Anonymous Coward () on
Comments
By SH () on
I'm sorry you see quoting Theo on the mailing list as a personal insult. That's pretty sad.
You apparently have a tenuous grip on reality. I've made a similar comment to another post on this forum, and I suppose it was you?
By sigh () on
By Anonymous Coward () on
Correlation does not imply causation. Certain not without without some discussion and research .
By theo the rat () on
about 14-15 hours a day for people to use
We've been spending hours and hours making openssh release
We are dealing with an, as far as we know, unexploitable hole
(affects some systems, but not openbsd it is pretty clear) issue
for all of you who run other system
we've been dealing with this frantically
to make something that the internet relies on as good
as good as it possibly can be
no sleep for 30 hours
and you expect me to treat you special?
AND YOU EXPECT ME TO TREAT YOU SPECIAL?
AND YOU THINK THAT PASTING THAT TO SOME IRC CHANNEL MAKES YOU LOOK
RIGHT?
and you think that you pasting it to some icb channel makes me feel
worth less, when every single hp and cisco switch containing this code
is likely vulnerable, and i don't like that, and want to make the
world a better place even if it kills me due to stress and lack of
sleep because i think that a better world is a better place to live
my life?
Comments
By Anonymous Coward () on
By Anonymous Coward () on
By () on
Comments
By SH () on
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
So you vet each and every product you buy with regards to the engineers' personality? I'm amazed.
What car do you drive? What hardware do you use? What brand of toothpaste is pure enough to pass your lips?
Comments
By Anonymous Coward () on
I just wish he could keep his mouth shut and roll with a punch or two. It's part of the gig man.
All that said I still like OpenBSD as a product.
Comments
By Anonymous Coward () on
By Anonymous Coward () on
Please release to the community a picture of you and your boyfriend from Argentina who works at CORE. We will then continue with sending you useful bugs to fix!!
Comments
By Anonymous Coward () on
By name protected () on
we're all well aware that, as always, the developers are doing everything they can to improve security all the time.
baiting the developers will not work: why do you think there have been next to no posts from developers here about this? clearly they are not interested in silly flame-wars. replying to bait from idiots won't help either - but i'm sure the rest of us share your sentiment and intentions :-)
as a professional software developer i have seen shocking code and i have seen good code. generally the good code is from the bigger open source projects (no, i'm not listing any because i'd just start another flame war), and the shocking code tends to be part of systems labelled "carrier grade" and sold for a million pounds upwards... go figure.
openbsd lives on side of "good code", along with a few other os projects that people get zealous about.
here's a challenge to those who want to sit and talk about openbsd code and security: get off your butt and get involved. buy "The Design and Implementation of the 4.4BSD Operating System" and get your hands dirty. but be careful, you won't be allowed to commit the same junk code you write at your day job.
if you're not a coder there are still many, many things you can do to help. if you can run autoconf and follow basic guidelines you have a headstart on helping the porters. if you can read or write any language (and i'm hoping that most people who post here can) you can help with the FAQ, miniFAQ's, man pages or other documentation.
come _on_ people! get involved. we're all busy, but even 20 minutes a day from each user will make a massive difference - put your skills to use and give a little back instead of just waiting for someone else to do it.
and no, i don't use capitalisation on weekends.
Comments
By Anonymous Coward () on
And a nice job on spoofing the IP field (just wish I had thought of doing it first :)
Comments
By Anonymous Coward () on
By Anonymous Coward () on
By Anonymous Coward () on
I hope you're not an openbsd developer because there's some really bad advice in that post not to mention support for really bad code.
In general, I would disagree with your comments about free software vs proprietary. In the end it all comes down to the maturity if the developers and the process(es) involved in the engineering side. There is a lot of really bad open source code, maybe not more (in quantity) than commercial stuff simply because there are less people producing output. Then again, there is Linux.
By Dino () on
By Anonymous Coward () on
Comments
By squid () on
Comments
By Anonymous Coward () on
Is the recent OpenSSH bug a reliability or security issue on Linux?
I know your answer will be "reliability", and that shows exactly what the problem is with this stupid classification. It's a marketing ploy so that OpenBSD doesn't have to call things security issues if their small minds think its unexploitable. History shows they've been proved wrong.
Comments
By squid () on
the distinction should be obvious to anyone with even the slightest sysadmin/development background. a security issue is one where a user can escalate their system privileges or otherwise attain access to data they normally not be able to access. a reliability issue is one where no such compromise of access-rights takes place, but rather results in the crashing of an application or an entire system.
don't get me wrong, they're both serious issues that need to be dealt with asap, but they are distinctly different. some admins may choose to treat a reliability issue with less importance than a security issue on small, low-traffic, less-critical systems. for example, i admin a number of small local networks for various local businesses (cvs repos, internal-business apps, etc.). some of them can't even be accessed (physically) from the net, and are relatively low traffic. so, if a reliability issue is found in one of those systems, i'm really in no hurry to fix it. it's not as important. the possiblity of some non-technically-inclined individual crashing an application/system on such a network is fairly remote. and even if they do, no big deal. it's a low traffic network that can stand to be down for 1/2 a day.
however, if that same reliability issue occurs in one of the networks attached to the internet, or a system with much higher volume of traffic, i will definitely give the issue top priority.
the term "reliability issue" was simply introduced as another means of catagorizing issues. if you wish to treat them as severe as security issues in all cases, then do so. but not everybody does.
and besides...we all know that most OpenBSD developers could care less what mainstream users think of their OS (and it shows...from the relatively unfriendly and unattainable tech support for newbies). so if OpenBSD was trying to launch a marketing campaign against mainstream users...they'd have to try a bit harder.
Comments
By Anonymous Coward () on
Comments
By Anonymous Coward () on
These developpers know their system by heart, and yes, it's possible that a 'reliability' is exploitable and, yes, that they don't know how, but at least they try (instead of cramming a lousy operating sytem down their user's throat like most popular linux-distros do).
If you know better, than please cooperate a little and show them examples, proof of concept, real exploits or simply better code.
Don't argue semantics. 'Reliability' and 'security' have overlapping areas. If obsd developpers find it not exploitable, and no-one proves the contrary - what do you expect.
Final note: PAX on linux may be technically better against exploits in general (compared to the different techniques in obsd), but that shouldn't be a reason for the linux security freaks to start a holy war against obsd. What do most companies run if they do run linux? They run redhat with an almost default install... go figure what's more secure. Obsd is more secure by default, anyone can deduct that. Ask yourself: how many companies do make use of grsecurity/pax/selinux/rsbac/whatever ? Not many, because it's far from mainstream.
Comments
By Anonymous Coward () on
on x86 possibly, stack pages are marked as supervisor.
on the sparc and alpha non-execution is handled in hardware, and so no little hacks are needed.
I guess the edge comes from a greater randomisation of mmaped pages.
Comments
By Anonymous Coward () on
Comments
By ulysses () on
By Anonymous Coward () on
would you like to explain it then ?
it appears as if all protected page table entries are set to supervisor. Each time we access one of these pages, the page fault handler is executed because the supervisor bit has been detected during the linear-to-physical address translation. That appears to be how pages are handled, segmexec works a bit like W^X, according to a grsecurity presentation.
The information on pages was derived from pageexec.txt, so if I am wrong, please correct me.
Plus PaX is for a useful OS. now you are just trolling
Comments
By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu
By squid () on
everybody "thinks" they have exploits for these bugs. i forgot that all it takes for somebody to create an exploit is for them to think it into existence.
once some actual exploit code is made public (that actually escalates the privileges of the user executing the code, rather than just crashing the app/machine), i'll believe it's a security issue. and yes, i've tried the recent code from noir and guninski, and it successfully crashed my machines. nothing more. thus, it's a reliability issue (at least on the versions i run, which are 3.3 and 3.4)
OpenBSD uses the term "security issue" when they believe there is even the slightest chance of a privilege-escalation taking place. check the errata page for 3.3, specifically issue 004. it's labelled "SECURITY" because they are unsure if the bug is exploitable. they recognize the fact that it could happen, even though no proof has been presented. the rest of the issues aren't exploitable because of the measures taken in the kernel to prevent various things such as this from happening. they're not downplaying the issues...they just know they're nothing more than reliability issues.
further, note that roughly half (7/13) of the issues on the 3.3 errata page are listed as "SECURITY" issues. they aren't afraid to address serious security issues.
By Anonymous Coward () on
Comments
By SH () on
Even when distros do support it, it is still unusable :http://forums.grsecurity.net/viewtopic.php?t=443&highlight=mandrake
However, even a newbie OpenBSD user can take advantage of W^X right out of the box.
So the question is really : What are the grsecurity developers doing to make useful technology usable to ordinary Linux users? Run Gentoo?
Comments
By Anonymous Coward () on
Comments
By SH () on
troll!
I had a good laugh when I read that comment. This is not Slashdot where claiming parent post is a troll gives you mod points.
But still, in what way is grsecurity useable to the ordinary SuSE, Redhat and Mandrake user?
In the case of Mandrake that does support grsecurity, what has PaX Team to say about it (grsecurity forum):
espicom wrote:
And the near total lack of anyone willing to answer how to fix it made it maddening!
maybe the following will sound a bit disappointing to you, but the fact is that grsecurity is supported on exactly one kernel version: vanilla from kernel.org. every other combination is the responsibility of the respective party who makes it (well, more or less, we do try to support some other patches as well, but only when they use the latest version which is not true for Mandrake). Mandrake's case is particularly painful as spender did try to tell them a while ago to keep using the latest versions, all in vain as you had to find it out the hard way. if the vanilla kernel is ok for you, please use it by all means, then we can actually support you, should you still run into problems.
Even a Mandrake user putting alot of effort to make grsecurity work, can't make it work.
In contrast to OpenBSD, anybody not using the standard Linux kernel is left on their own. That pretty much leaves the vast majority of Linux users on their own.
Comments
By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu
> In contrast to OpenBSD, anybody not using the standard Linux kernel is left on their own.
care to explain this poor guy's experience then (from http://marc.theaimsgroup.com/?l=openbsd-misc&m=106920547431350&w=2 ):
------------------------------------------------------------------------
I ask some guys here wich Kernel-Options I need. They told me USE GENERIC.
Even I wont use GENERIC, I use it. Couse I wont be able to analyse problems
(if there problems..).
The problem in my point of view is not the work of the developers, they do a
very well job(!), and it's not this guy with his exploit and not the hole
itselfs too. I think The problem is the maening about GENERIC and wich
things are "enabled" as default.
GENERIC isn't the answer at all and so we shouldn't damn people who aske for
options wich are not enabled/deactivated as default.
GENERIC is the first step. It's the base.
But maybe afterstep should told me in the next oBSD-Version that I've to
disable kerneloptions I never need.
Some weeks I asked what's happen if theres a hole into the kernel (and I
asked and used these compat-options as example) and some guys told me that's
"not possible". We see now it's possible so let change the mind about
GENERIC.
Patches are well but without this kernel-option I'm not affected and this is
fact and not a riddle.
So don't tell users again and again that they have to use GENERIC couse they
wont be supported if they've problems with a non GENERIC-Kernel.
I think it's sensless that nobody wont support me couse I enabled the
speed-hack...
------------------------------------------------------------------------
to paraphrase you, it sounds like as if 'anybody not using the standard OpenBSD kernel is left on their own'.
Comments
By SH () on
Comments
By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu
By Anonymous Coward () on
By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu
Comments
By SH () on
Grsecurity is _clearly usefull_, but for most it is also _unusable_. Even kernel patches is not enough, also userland should be supported as your post indicates : Grsecurity is fully supported in Gentoo throughout userland. You yourself want to use Propolice in combination with your own ideas to prevent some types of exploits. Do you think the above distros is going to use Propolice anytime soon?
The crux of it is this : OpenBSD developers made usefull technology usable. Unless you run Gentoo, grsecurity is not there yet.
Comments
By PaX Team () pageexec at freemail.hu on mailto:pageexec at freemail.hu
By Chris Humphries () chris@unixfu.net on http://unixfu.net/
You act like you are bound and can't do anything. You can change anything on the system to meet your needs, admin the box. If you are messing with grsecurity and other trustedos-ish os's then admining the box and getting it setup how you like it should take alot of your time initially.
The whole distro thing is kinda pointless if you can not even setup the box to how you like. I would also suggest you read the documentation on grsecurity that is available on their website.
educating yourself could have saved you some energy.