Re: new OpenSSL flaws
Theo, On Thu, Jun 05, 2014 at 04:38:24PM -0600, Theo de Raadt wrote: > Kurt and Solar -- > > You are the primary contacts for the oss-security email list. Kurt is not. I guess the reason why you got such impression was because Kurt invited you to join distros recently, not knowing that you had chosen not to join (not just you personally, but OpenBSD) in the private discussion we had in early 2012. I don't know it for sure, but I guess the reasons why Kurt and not someone else chose to (re-)invite OpenBSD included Kurt's past positive interactions with OpenBSD (e.g., I recall how he was welcome to work in the OpenBSD tent at HAL2001) and that he's an active participant on the distros list. He was just trying to help. I am hosting the oss-security (public), and distros and linux-distros lists (private). So I am administrative contact for these lists. Additionally, this means that if the community starts asking for things I have strong feelings against, or I feel the private lists are causing more harm than they provide benefit (a tough balance, and there's no clear way to measure it), I may stop hosting the lists (this is why they stay "experimental" - perhaps permanently so, although we might adjust/remove the wording if it confuses people). Now to your specific questions: > Are you are aware of any operating system, product suppliers, or > service providers who were notified early by OpenSSL... but are not > found on the private mailing list? I am only aware of what's in the timeline you already saw (the one I posted to oss-security, taken from Mark Cox's Google+ post). Per that timeline, yes, there were notifications beyond distros list members: 2014-06-02 CERT/CC notify their distribution list about the security update but with no details 2014-06-03 "ops-trust" (1015) and selected OpenSSL Foundation contracts (0820) are told a security update will be released on 2014-06-05 but with no details We (Openwall) did receive a notification from CERT/CC (with no detail, as the timeline correctly says). As to whether/why OpenBSD wasn't notified by CERT/CC, I don't know. > I think it would be poor style to ask for specific names, but a > vague statement confirming or denying things would be nice. I don't even know any specific names of additional vendors CERT/CC might have notified, and I don't know who's "ops-trust" and "selected OpenSSL Foundation contracts". So the above is as specific as I have. > There are claims that attendance on your private email list is > required & sufficient for early disclosure from OpenSSL. Per the above, it appears not to be the only way. As to it being sufficient, I don't know what OpenSSL team's intent is - it is up to them who and what lists to disclose to. To me, it does appear likely that they will continue notifying the distros list, but this is not any sort of authoritative answer since I'm not with OpenSSL. > Thanks in advance for any clarity you can supply to this question. I hope the answers above help. Alexander
mail server - Oracale/Sun X4-2
Greetings, I need to replace an aging Sun Fire V215 (SPARC-64bit) mail server. I am thinking of using an Oracle/Sun X4-2(1 x Xeon E5-2650 v2 8-core 2.6 GHz CPU internal Sun Storage 6 GB SAS PCI HBA) and two internal 300 GB1 rpm 2.5-inch SAS-2 HDD), as unfortunately small SPARC servers are not manufactured anymore. Any good/bad experiences with the X4-2 servers? Ioan
mail server - Oracale/Sun X4-2
Greetings, I need to replace an aging Sun Fire V215 (SPARC-64bit) mail server. I am thinking of using an Oracle/Sun X4-2(1 x Xeon E5-2650 v2 8-core 2.6 GHz CPU internal Sun Storage 6 GB SAS PCI HBA) andtwo internal 300 GB1 rpm 2.5-inch SAS-2 HDD), as unfortunately small SPARC servers are not manufactured anymore. Any good/bad experiences with the X4-2 servers? Ioan
Re: that private mailing list
I'll top-post this one time, to quote Chris' message in its entirety. I've dropped the CC to secur...@redhat.com - it felt too spammy to be sending them this. I've added Kurt, who is already involved in the discussion. Theo - Thank you for (apparently) forwarding my reply to your team. I was uncomfortable about not being able to refer to that private discussion in the thread you started on your lists. Somehow I don't see that message appearing on your lists, though? Luckily, Chris quoted most of that one message, so at least that portion is now public. Chris, the answer to your "really?" and "seriously?" is "yes, really and seriously". I am being sincere. I'll now proceed to provide replies to specific questions address to me in other messages. On Thu, Jun 05, 2014 at 10:10:57PM -0700, Chris Cappuccio wrote: > Theo de Raadt [dera...@cvs.openbsd.org] wrote: > > From: Solar Designer > > To: Theo de Raadt > > > > Hi Theo, > > > > I can't comment about OpenSSL folks, but my own impression certainly was > > that you didn't want your project to be provided advance notification - > > not only via distros list, but at all. Now you're saying you actually > > wanted folks on your team to be notified, just not you personally. Hmm? > > Really? > > Let's see it. I'm questioning your judgment after reading the next bit. > > > As you had mentioned to me in the private discussion when stu@ wanted to > > get OpenBSD onto distros, you didn't want folks on your team to accept > > any kind of embargo. I wish we had that discussion in public, as I had > > suggested at the time. You objected to that. (And I understand that > > with that discussion in public you might not have been willing to blame > > some others in it, which would possibly hamper my understanding of your > > position. So your objection did make some sense.) Now you appear to be > > misinforming folks on your own team (I hope not intentionally) that > > those evil people on distros list and OpenSSL maintainers deliberately > > didn't want to notify you. You might be right about OpenSSL maintainers > > (although I think you are not) - I just don't know, and can't speak for > > them - but at least for me (as someone who was notified via distros > > list) it appeared that you actually didn't want your team to be notified > > in a manner that would impose any restrictions on when you can commit a > > fix. So, believe it or not, it didn't even occur to me to put your > > project in a position where your folks would be asked to accept an > > embargo, which you didn't want. > > > > This reads like some kind of strange combination of arbitrary logic > and reasoning to justify this in your own mind. > > Firstly, an "embargo" is crap and you know it. That implies a formal > process with contracts and legal implications. (More plainly, did YOU sign?) > > A heads-up from OpenSSL to the key people is all it would have taken. > (Sorry, I guess that's only appropriate when those key people aren't aiming > at improving their shitty product.) > > > Would you like me to suggest (to whoever reports an issue) that someone > > on your team (who?) be notified next time an OpenSSL issue is brought up > > on distros? (It doesn't have to be one person on your team - it can be > > several. This is to address Bob's comment on your lists.) What about > > issues in other projects (not OpenSSL)? Which other projects would you > > also like notifications about? > > > > It appears that you've made a (political) decision for your projects not > > to join distros (or possibly any such channels in general), but are now > > asking for people/projects to be notifying your folks anyway when > > appropriate (whatever that means), and this is difficult for everyone. > > > > How do you suggest we make things better (in whatever sense you like) > > going forward? > > > > Seriously? > > I think the situation here is PLAINLY OBVIOUS. > > Here in the real world, key OpenBSD members should be trusted to > do the RIGHT THING in a typical situation like this. > > This isn't the first time this has happened nor the last time it will. > > Hopefully next time someone has common sense. > > I think we can all agree, OpenSSH has been successful at mitigating > this same kind of problem with ALL of the other players. > > Maybe you need some coffee? > > Chris
Re: that private mailing list
Theo de Raadt [dera...@cvs.openbsd.org] wrote: > From: Solar Designer > To: Theo de Raadt > > Hi Theo, > > I can't comment about OpenSSL folks, but my own impression certainly was > that you didn't want your project to be provided advance notification - > not only via distros list, but at all. Now you're saying you actually > wanted folks on your team to be notified, just not you personally. Hmm? Really? Let's see it. I'm questioning your judgment after reading the next bit. > As you had mentioned to me in the private discussion when stu@ wanted to > get OpenBSD onto distros, you didn't want folks on your team to accept > any kind of embargo. I wish we had that discussion in public, as I had > suggested at the time. You objected to that. (And I understand that > with that discussion in public you might not have been willing to blame > some others in it, which would possibly hamper my understanding of your > position. So your objection did make some sense.) Now you appear to be > misinforming folks on your own team (I hope not intentionally) that > those evil people on distros list and OpenSSL maintainers deliberately > didn't want to notify you. You might be right about OpenSSL maintainers > (although I think you are not) - I just don't know, and can't speak for > them - but at least for me (as someone who was notified via distros > list) it appeared that you actually didn't want your team to be notified > in a manner that would impose any restrictions on when you can commit a > fix. So, believe it or not, it didn't even occur to me to put your > project in a position where your folks would be asked to accept an > embargo, which you didn't want. > This reads like some kind of strange combination of arbitrary logic and reasoning to justify this in your own mind. Firstly, an "embargo" is crap and you know it. That implies a formal process with contracts and legal implications. (More plainly, did YOU sign?) A heads-up from OpenSSL to the key people is all it would have taken. (Sorry, I guess that's only appropriate when those key people aren't aiming at improving their shitty product.) > Would you like me to suggest (to whoever reports an issue) that someone > on your team (who?) be notified next time an OpenSSL issue is brought up > on distros? (It doesn't have to be one person on your team - it can be > several. This is to address Bob's comment on your lists.) What about > issues in other projects (not OpenSSL)? Which other projects would you > also like notifications about? > > It appears that you've made a (political) decision for your projects not > to join distros (or possibly any such channels in general), but are now > asking for people/projects to be notifying your folks anyway when > appropriate (whatever that means), and this is difficult for everyone. > > How do you suggest we make things better (in whatever sense you like) > going forward? > Seriously? I think the situation here is PLAINLY OBVIOUS. Here in the real world, key OpenBSD members should be trusted to do the RIGHT THING in a typical situation like this. This isn't the first time this has happened nor the last time it will. Hopefully next time someone has common sense. I think we can all agree, OpenSSH has been successful at mitigating this same kind of problem with ALL of the other players. Maybe you need some coffee? Chris
Re: that private mailing list
> Would you like me to suggest (to whoever reports an issue) that someone > on your team (who?) be notified next time an OpenSSL issue is brought up > on distros? Solar and Kurt, a few questions: Your one-word answers to the following questions will decide your reputation regarding open source security, my reputation regarding open source security, or the reputation of others. 1. Was full and complete advance disclosure of this issue managed via your list? Answer yes or no. One word. 2. Previous to this morning, were you aware that OpenBSD was not receiving this information? Answer yes or no. One word. 3. In your hearts, do you believe that a subtantial subset of open source OS users, via their vendor contacts, should ever accept a late delivery of information for any reason? Answer yes or no. One word. 4. Were you party to a late disclosure to OpenBSD? Answer yes or no. One word. Kurt and Solar, I am aware I am including people you have business with. I hope you realize that this is the day you are called to tell the truth or tell a lie. It happens to us all. Lack of an answer will judge you, worse than inaction from me. That is why I am sending this mail. I wish it wasn't this way, but when were OpenBSD users asked their point of view regarding their security? Right now, I am asking for an account of who caused them to not know at the same time as others.
Re: new OpenSSL flaws
Miod Vallat [m...@online.fr] wrote: > > Now you have and example of how they are unwilling to work with you next > > time someone asks why not work with OpenSSL on fixing it. Pretty direct > > proof. > > The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE. > > We believe in peer review; they don't give a sh*t about it (as shown > less than a month ago by the way their #3317 bug was fixed, commiting a > different fix from the proposed one and introducing a stupid *and > obvious* bug in the process - which got fixed the next day after otto@ > mentioned it to the OpenSSL developers). > > If you can't trust people to apply one-liner fixes correctly, can you > trust them for anything serious? I think this Networkworld article says it all... (and since when did interesting, critical analysis come from Networkworld!?) http://www.networkworld.com/article/2360229/microsoft-subnet/critical-flaw-in-encryption-has-been-in-openssl-code-for-over-15-years.html If you don't think that Robin Seggelmann is a paid stooge actively trying to sabotage OpenSSL (an idea rooted in paranoia?) then you may at least think he is careless, unable to use critical thought, and certainly doesn't need commit access to any source code repository. Am I late to the party? Or is it time to re-audit every single character of his code? In the mean time, let Dr. Stephen N. Strangelove continue his mad plan to support VMS and Windows 3.1. Let him play games with LibreSSL "competitors" by denying advance notice. Perhaps next time Otto won't bother to inform them about their new stupid, obvious flaws in return? It's low class for Dr. Strangelove and his team to behave like this, after the many repetitive attempts from @openbsd.org to bring OpenSSL into the new century. OpenSSH became the de-facto standard because it was the only serious free alternative for a long time. OpenSSL has always been free. So the culture difference is precisely what will drive people for, or away from OpenSSL. (People from the culture of supporting ancient software and broken standards are going to choose OpenSSL every time!)
[no subject]
Fcc: +outbox Subject: Re: that private mailing list (fwd) Solar Designer: Re: that private mailing list I haven't even read this. I don't care. if this is the situation with open source disclosure, all of you users are fucked. --- Forwarded Message Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by cvs.openbsd.org (8.14.8/8.12.1) with SMTP id s564LjFg027340 for ; Thu, 5 Jun 2014 22:21:46 -0600 (MDT) Received: (qmail 19629 invoked from network); 6 Jun 2014 04:21:39 - Received: from localhost (HELO pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 6 Jun 2014 04:21:39 - Received: by pvt.openwall.com (Postfix, from userid 503) id 82DA048BCE; Fri, 6 Jun 2014 08:21:05 +0400 (MSK) Date: Fri, 6 Jun 2014 08:21:05 +0400 From: Solar Designer To: Theo de Raadt Subject: Re: that private mailing list Message-ID: <20140606042105.gb26...@openwall.com> References: <201406052157.s55lvh7j020...@cvs.openbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406052157.s55lvh7j020...@cvs.openbsd.org> User-Agent: Mutt/1.4.2.3i Hi Theo, I'll reply only in private first, because I am referring to the past discussion we had in private and that you didn't want to be made public. Also, please note that I wrote the below with no hard feelings, and I don't mean to offend you. I am just being sincere and direct. I think that is your preferred way to communicate, so I've adopted it. :-) On Thu, Jun 05, 2014 at 03:57:43PM -0600, Theo de Raadt wrote: > I only know parts. It sound like some people who claim they stand > up for what is right really don't stand up for what is right. I can't comment about OpenSSL folks, but my own impression certainly was that you didn't want your project to be provided advance notification - not only via distros list, but at all. Now you're saying you actually wanted folks on your team to be notified, just not you personally. Hmm? As you had mentioned to me in the private discussion when stu@ wanted to get OpenBSD onto distros, you didn't want folks on your team to accept any kind of embargo. I wish we had that discussion in public, as I had suggested at the time. You objected to that. (And I understand that with that discussion in public you might not have been willing to blame some others in it, which would possibly hamper my understanding of your position. So your objection did make some sense.) Now you appear to be misinforming folks on your own team (I hope not intentionally) that those evil people on distros list and OpenSSL maintainers deliberately didn't want to notify you. You might be right about OpenSSL maintainers (although I think you are not) - I just don't know, and can't speak for them - but at least for me (as someone who was notified via distros list) it appeared that you actually didn't want your team to be notified in a manner that would impose any restrictions on when you can commit a fix. So, believe it or not, it didn't even occur to me to put your project in a position where your folks would be asked to accept an embargo, which you didn't want. Would you like me to suggest (to whoever reports an issue) that someone on your team (who?) be notified next time an OpenSSL issue is brought up on distros? (It doesn't have to be one person on your team - it can be several. This is to address Bob's comment on your lists.) What about issues in other projects (not OpenSSL)? Which other projects would you also like notifications about? It appears that you've made a (political) decision for your projects not to join distros (or possibly any such channels in general), but are now asking for people/projects to be notifying your folks anyway when appropriate (whatever that means), and this is difficult for everyone. How do you suggest we make things better (in whatever sense you like) going forward? /sd --- End of Forwarded Message
Re: new OpenSSL flaws
> I suggest you talk to Mark Cox who actually handled this stuff. I'm not > sure why you are asking two people (myself and Solar) who are NOT part of > the OpenSSL team about whom the OpenSSL team notified. Kurt, if Mark Cox is the person who handled this stuff, fine. Who cares? I am hearing claims all over the place regarding a list RUN BY YOU. FACT: Kurt Seifried and Solar Designer are the two primary operators of the openwall security list, the declared access point for security issues affecting Linux operating systems. There are claims being lodged that disclosure of these OpenSSL problems happened on that list. There are claims that we did not get this disclosure because OpenBSD is not on that list. Particularily me, Bob, and Todd Miller. Kurd, is that true? Is that how you see it? Were disclosures handled there, or via another platform or method? ANSWER THE QUESTION. If you won't answer this question, noone should ever trust you again for anything. > I'm done playing games with you Theo. You were invited to join distros > publicly and flamed me. I privately emailed Bob Beck inviting him to join, > and he flamed me (but then apologized), You both said no. I can't do > anything more. I wish you the best of luck in your future endeavors. I am not playing any games. Let's look at the facts. Kurd Seifried is an official Red Hat security officer (of sorts, but probably not tomorrow) Kurt, is Mark Cox your supervisor? A claim is being made that disclosure to OpenBSD needs to be on a Russian email list run by you (Kurt Seifried) and Solar Designer (not going to include his real name) for access to early disclosure of important security information. SO ANSWER THE FUCKING QUESTION, KURT. Or else, if you are a wimp, have your Mark Cox answer the fucking question. Red Hat and OpenSSL -- answer the fucking question. Why was the OpenBSD user community excluded from this information? Why are there public accusation -- from Red Hat officers -- that OpenBSD developers only get advance access to information if they join a Russian located email list? ps. Who is Mark Cox? I've never heard of him.
Re: Weird disk problem
On Thu, Jun 5, 2014, at 05:24 PM, STeve Andre' wrote: > On 06/05/14 17:38, Christian Weisgerber wrote: > > I have a 3TB disk here... > > > > sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct > > fixed naa.5000cca225c5fbeb > > sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors > > > > ... that's serving as a general media dump with a single FFS2 file > > system on it. > > > > Filesystem SizeUsed Avail Capacity Mounted on > > /dev/sd1d 2.7T2.5T 63.7G98%/export > > > > Yesterday, I experienced the odd effect that reading some files, > > or parts of files, from that disk became excruciatingly slow. We're > > talking a few kB/s here. Other files were fine. There were no > > kernel errors/warnings whatsoever. There were no read errors, the > > disk was just 100% busy and appeared to be returning data drip by > > drip. > > > > # atactl sd1 smartstatus > > No SMART threshold exceeded > > > > No change on reboot. dd(1) from the raw device was initially fast, > > then slowed to a crawl as it progressed. I eventually "fixed" it > > all by powering off the machine, jiggling the SATA connectors (all > > fine), and powering the machine back up. > > > > Tonight the problem is back. Something is very wrong. Given that > > dd if=/dev/rsd1c also seems affected, the filesystem layer can be > > excluded. I won't cry too much over a dying disk, but why the heck > > are there no error indications of any kind? > > > > Any other ideas? Anything in dmesg/kernel log about operations timing out? > I think you are relying on the smart system too much. Certainly try > what David said, but it's obvious that the disk is sick despite what the > smart system may say. > > I've had about seven disk failures in the last several years. Three or > four of them the smart system was absolutely correct, with the others > being less informative. I've also had a false notice that a disk was > bad, > but worked for several years, till it got too small for its task. > > Smart is good, but it has its limitations. It best deals with gradual > errors, not fast catastrophic ones. Running smartmontools should give you enough information to determine if you have a sick disk, though it may require looking at the values and seeing if you have a rise in e.g. the number of sectors remapped; I would not trust "atactl sd# smartstatus" by itself. Failing that, there are more time-honored empirical tests, such as assuming the worst for the disk's health if it is making weird noises when it slows to a crawl. It could also be either the SATA cabling or the SATA controller that is having trouble after warming up (with specific bit patterns, or just in general). I know that sounds weird, but SATA cables aren't that expensive to replace and it's quite possible the OP got a dud. -- Shawn K. Quinn skqu...@rushpost.com
Re: new OpenSSL flaws
On Thu, Jun 5, 2014, at 08:36 PM, Giancarlo Razzolini wrote: > Em 05-06-2014 21:23, David Goldsmith escreveu: > > Probably ipfilter > > > > > http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls-from-ipf-to-pf-on.html > > > If it is indeed ipfilter, I don't think OpenSSL will have the same fate. > There is lots of money on it, and even more now, that the Linux > Foundation is funding them directly. I believe that LibreSSL and OpenSSL > will live alongside for a long time. That's a valid opinion, but as I said, I doubt it. Vendors aren't stupid. With all that has happened lately, given a choice the switch will not take long.
Re: new OpenSSL flaws
On Jun 5, 2014, at 8:09 PM, Giancarlo Razzolini wrote: > Em 05-06-2014 20:45, Eric Furman escreveu: >> I predict that within a year OpenSSL will go the way of IPF. >> For much the same reason... >> > IPF? Care to elaborate? > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC Probably ipfilter http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls- from-ipf-to-pf-on.html -- David Goldsmith [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: new OpenSSL flaws
Em 05-06-2014 21:23, David Goldsmith escreveu: > Probably ipfilter > > http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls-from-ipf-to-pf-on.html > If it is indeed ipfilter, I don't think OpenSSL will have the same fate. There is lots of money on it, and even more now, that the Linux Foundation is funding them directly. I believe that LibreSSL and OpenSSL will live alongside for a long time. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
On Thu, Jun 5, 2014 at 5:09 PM, Giancarlo Razzolini wrote: > Em 05-06-2014 20:45, Eric Furman escreveu: >> I predict that within a year OpenSSL will go the way of IPF. >> For much the same reason... >> > IPF? Care to elaborate? Well, in 2001 there was this drama around Darren Reed's IPF, that caused it to be removed from OpenBSD's source code. This removal and license problem directly to the development of OpenBSD's pf firewall by Daniel Hartmeier. And the rest, as they say, is history.
Re: new OpenSSL flaws
I may also remind people that those lists are acknowledged right at the top as experimental. They also do not allow for non personal subscriptions, so they aren't very practical for this. What if I was away for a day or three.. Or more.. Essentially this is a nice experiment, but not really a practical means of early disclosure. Nor were we informed it was anything beyond experimental. On 5 Jun 2014 17:39, "Stuart Henderson" wrote: > On 2014/06/05 20:43, Martin, Matthew wrote: > > > That's exactly my though. Specially, because FreeBSD and NetBSD were > > > warned, but not OpenBSD. If this was only a rant or any childish > > > behavior from them, it's something stupid and, of course, not the right > > > thing to do. But hey, we're all human. My real concern is if this > > > something else, a hidden agenda, in that this "stupid disclosure" was > > > indeed, carefully planed. One can never have too many conspiracy > > > theories. Specially after what has been happening the last year. Thanks > > > for the clarification. > > > > Mark Cox claims that the reason OpenBSD was not told is because OpenBSD > > is not on the distros mailing list and if we were then "they'd be able > > to work with other distros on issues in advance." > > The distros and linux-distros lists are a good way to contact *some* > OS distributions and Amazon. > > http://oss-security.openwall.org/wiki/mailing-lists/distros > > But there are clearly a number of others for whom an OpenSSL bug > would have big impact who are not on that list (OS such as OpenBSD > and Apple, large scale hosting providers, etc). Many of these are > listed on the security contacts page on the wiki, and actually, the > page with information about sending to the distros list (which > submitters cannot ignore as it has the required pgp key) says: > > "Please notify upstream projects/developers of the > affected software, other affected distro vendors http://oss-security.openwall.org/wiki/vendors>, and/or > affected Open Source projects before notifying one of these > mailing lists in order to ensure that these other parties > are OK with the maximum embargo period that would apply."
Re: new OpenSSL flaws
Em 05-06-2014 20:45, Eric Furman escreveu: > I predict that within a year OpenSSL will go the way of IPF. > For much the same reason... > IPF? Care to elaborate? -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
I predict that within a year OpenSSL will go the way of IPF. For much the same reason...
Re: new OpenSSL flaws
On 2014/06/05 20:43, Martin, Matthew wrote: > > That's exactly my though. Specially, because FreeBSD and NetBSD were > > warned, but not OpenBSD. If this was only a rant or any childish > > behavior from them, it's something stupid and, of course, not the right > > thing to do. But hey, we're all human. My real concern is if this > > something else, a hidden agenda, in that this "stupid disclosure" was > > indeed, carefully planed. One can never have too many conspiracy > > theories. Specially after what has been happening the last year. Thanks > > for the clarification. > > Mark Cox claims that the reason OpenBSD was not told is because OpenBSD > is not on the distros mailing list and if we were then "they'd be able > to work with other distros on issues in advance." The distros and linux-distros lists are a good way to contact *some* OS distributions and Amazon. http://oss-security.openwall.org/wiki/mailing-lists/distros But there are clearly a number of others for whom an OpenSSL bug would have big impact who are not on that list (OS such as OpenBSD and Apple, large scale hosting providers, etc). Many of these are listed on the security contacts page on the wiki, and actually, the page with information about sending to the distros list (which submitters cannot ignore as it has the required pgp key) says: "Please notify upstream projects/developers of the affected software, other affected distro vendors http://oss-security.openwall.org/wiki/vendors>, and/or affected Open Source projects before notifying one of these mailing lists in order to ensure that these other parties are OK with the maximum embargo period that would apply."
Re: new OpenSSL flaws
Em 05-06-2014 19:43, Bob Beck escreveu: > For the record, we didn't get advance notice of Heartbleed either, so > this is nothing new. Bob, I didn't knew that. I feel like I've released a monster (Cthulhu anyone?). I was just curious when I asked Theo if this did happened before. It's possible that someone else would also ask him that. Anyway, this kind of thing hurts the entire FLOSS movement. The whole point of writing a open source project is collaboration. It seems that OpenSSL took a step backward on this. Now, I wonder, if there won't be LibreSSL code appearing on OpenSSL. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
We are not on a linux distros mailing list, because we are not a linux distribution. And this private mailing list is not really an acknowledged conduit for vulnerability release. I was asked by someone privately if *I* would be on that mailing list on June 2nd. I said I would consider it, but as I felt the list was not being used for advanced disclosure in a practical means, I didn't see the reason for it. - but I would be open to it if it was being used for advanced disclosure.. my words on june 2 ended with: >In a nutshell, I suppose I'm asking you - does this help if the list only gets >notification at the same time, basically, as public release? > >Or are there some "rules" for participants? The reply I got said they couldn't give any details because there were not any - so obviously as of June 2, someone who was on and maintained that list did not feel that there was any need to be on the list for advance disclosure of bugs. For the record, we didn't get advance notice of Heartbleed either, so this is nothing new. On Thu, Jun 5, 2014 at 2:43 PM, Martin, Matthew wrote: >> That's exactly my though. Specially, because FreeBSD and NetBSD were >> warned, but not OpenBSD. If this was only a rant or any childish >> behavior from them, it's something stupid and, of course, not the right >> thing to do. But hey, we're all human. My real concern is if this >> something else, a hidden agenda, in that this "stupid disclosure" was >> indeed, carefully planed. One can never have too many conspiracy >> theories. Specially after what has been happening the last year. Thanks >> for the clarification. > > Mark Cox claims that the reason OpenBSD was not told is because OpenBSD > is not on the distros mailing list and if we were then "they'd be able > to work with other distros on issues in advance." > > It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . > > Not saying I believe or disbelieve him, but it can't hurt to join even > if it is only until 5.6 comes out. > > - Matthew Martin
Re: new OpenSSL flaws
> Not saying I believe or disbelieve him, but it can't hurt to join even > if it is only until 5.6 comes out. Another way to phrase this is The OpenBSD user community should accept they have suffered because Theo declined an invitation to a private email list, entirely unrelated to the vendor who was in control of deciding where the notification would go. Right. That's a good one. I will not join that list. It would not have helped. I do not do work in SSL; there's 10 other people on our group who do that. Shall I send a request that all 10 of our SSL sub-group join that list, because there's a lot of SSL-related shit coming down the pipe soon? Heck, why don't they just let anyone join...
Re: new OpenSSL flaws
> > That's exactly my though. Specially, because FreeBSD and NetBSD were > > warned, but not OpenBSD. If this was only a rant or any childish > > behavior from them, it's something stupid and, of course, not the right > > thing to do. But hey, we're all human. My real concern is if this > > something else, a hidden agenda, in that this "stupid disclosure" was > > indeed, carefully planed. One can never have too many conspiracy > > theories. Specially after what has been happening the last year. Thanks > > for the clarification. > > Mark Cox claims that the reason OpenBSD was not told is because OpenBSD > is not on the distros mailing list and if we were then "they'd be able > to work with other distros on issues in advance." > > It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . > > Not saying I believe or disbelieve him, but it can't hurt to join even > if it is only until 5.6 comes out. That is an interesting claim. It sounds like we should test it, rather than take it as fact. Let's ask the right people. Kurt and Solar -- You are the primary contacts for the oss-security email list. Are you are aware of any operating system, product suppliers, or service providers who were notified early by OpenSSL... but are not found on the private mailing list? I think it would be poor style to ask for specific names, but a vague statement confirming or denying things would be nice. There are claims that attendance on your private email list is required & sufficient for early disclosure from OpenSSL. Thanks in advance for any clarity you can supply to this question.
Re: new OpenSSL flaws
> That's exactly my though. Specially, because FreeBSD and NetBSD were > warned, but not OpenBSD. If this was only a rant or any childish > behavior from them, it's something stupid and, of course, not the right > thing to do. But hey, we're all human. My real concern is if this > something else, a hidden agenda, in that this "stupid disclosure" was > indeed, carefully planed. One can never have too many conspiracy > theories. Specially after what has been happening the last year. Thanks > for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then "they'd be able to work with other distros on issues in advance." It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. - Matthew Martin
Re: Weird disk problem
On 06/05/14 17:38, Christian Weisgerber wrote: I have a 3TB disk here... sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5000cca225c5fbeb sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors ... that's serving as a general media dump with a single FFS2 file system on it. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1d 2.7T2.5T 63.7G98%/export Yesterday, I experienced the odd effect that reading some files, or parts of files, from that disk became excruciatingly slow. We're talking a few kB/s here. Other files were fine. There were no kernel errors/warnings whatsoever. There were no read errors, the disk was just 100% busy and appeared to be returning data drip by drip. # atactl sd1 smartstatus No SMART threshold exceeded No change on reboot. dd(1) from the raw device was initially fast, then slowed to a crawl as it progressed. I eventually "fixed" it all by powering off the machine, jiggling the SATA connectors (all fine), and powering the machine back up. Tonight the problem is back. Something is very wrong. Given that dd if=/dev/rsd1c also seems affected, the filesystem layer can be excluded. I won't cry too much over a dying disk, but why the heck are there no error indications of any kind? Any other ideas? I think you are relying on the smart system too much. Certainly try what David said, but it's obvious that the disk is sick despite what the smart system may say. I've had about seven disk failures in the last several years. Three or four of them the smart system was absolutely correct, with the others being less informative. I've also had a false notice that a disk was bad, but worked for several years, till it got too small for its task. Smart is good, but it has its limitations. It best deals with gradual errors, not fast catastrophic ones. --STeve Andre'
Re: Weird disk problem
On Thu, 5 Jun 2014, Christian Weisgerber wrote: I have a 3TB disk here... sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5000cca225c5fbeb sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors ... that's serving as a general media dump with a single FFS2 file system on it. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1d 2.7T2.5T 63.7G98%/export Yesterday, I experienced the odd effect that reading some files, or parts of files, from that disk became excruciatingly slow. We're talking a few kB/s here. Other files were fine. There were no kernel errors/warnings whatsoever. There were no read errors, the disk was just 100% busy and appeared to be returning data drip by drip. # atactl sd1 smartstatus No SMART threshold exceeded No change on reboot. dd(1) from the raw device was initially fast, then slowed to a crawl as it progressed. I eventually "fixed" it all by powering off the machine, jiggling the SATA connectors (all fine), and powering the machine back up. Tonight the problem is back. Something is very wrong. Given that dd if=/dev/rsd1c also seems affected, the filesystem layer can be excluded. I won't cry too much over a dying disk, but why the heck are there no error indications of any kind? Any other ideas? Did you try smartctl from smartmontools for a more detailed report? My favourite are: smartctl -a /dev/sd1c smartctl -l scttemp /dev/sd1c smartctl -t short /dev/sd1c smartctl -t long /dev/sd1c (will take several hours!!!) smartctl -a /dev/sd1c (again after each of the tests) Regards, David
Weird disk problem
I have a 3TB disk here... sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5000cca225c5fbeb sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors ... that's serving as a general media dump with a single FFS2 file system on it. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1d 2.7T2.5T 63.7G98%/export Yesterday, I experienced the odd effect that reading some files, or parts of files, from that disk became excruciatingly slow. We're talking a few kB/s here. Other files were fine. There were no kernel errors/warnings whatsoever. There were no read errors, the disk was just 100% busy and appeared to be returning data drip by drip. # atactl sd1 smartstatus No SMART threshold exceeded No change on reboot. dd(1) from the raw device was initially fast, then slowed to a crawl as it progressed. I eventually "fixed" it all by powering off the machine, jiggling the SATA connectors (all fine), and powering the machine back up. Tonight the problem is back. Something is very wrong. Given that dd if=/dev/rsd1c also seems affected, the filesystem layer can be excluded. I won't cry too much over a dying disk, but why the heck are there no error indications of any kind? Any other ideas? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: CPU power consumption on thinkpad x201 on openbsd current
On 2014-06-05 20:43, Mike Larkin wrote: On Thu, Jun 05, 2014 at 10:53:38AM +0200, Johan Svensson wrote: On 06/05/14 00:53, STeve Andre' wrote: On 06/04/14 17:08, Johan Svensson wrote: I'm trying to migrate from Linux to Openbsd on my laptop (thinkpad x201). The first problem that i came across was that the Cpu fanspeed was running constantly at 3500RPM. After the acpithinkpad.c patch from jcs (and i modified to make it work on the openbsd-current(link: http://exclude.se/patch/jcs_mod_by_js.diff) Another thing that i noticed is that the battery lifetime is really bad. In Linux i get around ~5,5 hours. In OpenBSD i get around 2 hours. when i ran : sysctl hw.sensors | grep -i consumption. the output of the cpu was 6W. in Linux it's around 1,5W. with: apmd -C and apmd -L it's the same. dmesg: http://exclude.se/openbsd/dmesg.txt Is there anyway to fix this? Regards Johan Svensson Take a look at hw.setperf in sysctl. I think you are running at the maximum cpu speed? On my 2.8GHz W500 I can run at 800, 1600, 2133 and 2801. 800MHz makes a huge difference. You have to try different values for setperf to see what happens. sysctl will also tell you the speed in hw.cpuspeed. --STeve Andre' This my output from sysctl and apm when running on the lowest clockspeed: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1959 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=1199 hw.setperf=0 # apm Battery state: high, 70% remaining, 111 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (1199 MHz) This is the output when i use apm -H: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1972 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=2666 hw.setperf=100 # apm Battery state: high, 68% remaining, 107 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (2666 MHz) The energy consumption is the same which is odd. --Johan This may be a bug in itherm(4), I'll take a look. Tell me if you find something, i'll gladly help if I could do something. /J
Re: new OpenSSL flaws
> >Is clear that the second process -- intending to also take an ethical > >path for disclosure -- should not specifically exclude a part of the > >community. > > They specifically exclude parts of the community that specifically > say they don't want to be INCLUDED. > > See: http://seclists.org/oss-sec/2014/q2/233 Dear Anonymous, That discussion is unrelated. I made a personal statement that I did not wish to participate in another private mailing list, stating my reasons as clearly as I could. My personal participation in such a mailing list is very distinct from OpenSSL's social responsibility to inform - the 10+ developers working on LibreSSL (I am only a minor part of that sub-group). - the security-concerned sub-group of OpenBSD (I play a big part in that, but not in regards to the SSL subset, so at most I would have handed this to the LibreSSL subgroup) Dr. Henson of OpenSSL knew who to contact. The other members of the private mailing list were witness to the disclosure gap. The choice was made there. I cannot be held responsible for this lack of notification.
Re: Gnome 3, toad and my android phone
I tried a few things and use FTPDroid now, which works nicely for my needs (getting the pictures from the phone). Thats even easier than connecting a cable everytime. Thanks to everyone contributing! Nils
Re: new OpenSSL flaws
On 6/5/2014 4:02 PM, Miod Vallat wrote: Now you have and example of how they are unwilling to work with you next time someone asks why not work with OpenSSL on fixing it. Pretty direct proof. The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE. We believe in peer review; they don't give a sh*t about it (as shown less than a month ago by the way their #3317 bug was fixed, commiting a different fix from the proposed one and introducing a stupid *and obvious* bug in the process - which got fixed the next day after otto@ mentioned it to the OpenSSL developers). If you can't trust people to apply one-liner fixes correctly, can you trust them for anything serious? *I* know that. Yet every time someone interviews someone from OpenBSD about LibreSSL it's always "Why fork it? Why not work with them?" This is a nice succinct example about how OpenSSL has no interest in working with you. Not that we really want them to after looking at the code base. --Kurt
Re: new OpenSSL flaws
On Thu, Jun 05, 2014 at 08:02:58PM +, Miod Vallat wrote: > > If you can't trust people to apply one-liner fixes correctly, can you > trust them for anything serious? I really don't like to point fingers, but... It is done by the same people that introduced the Debian random number bug back in 2006: http://www.gergely.risko.hu/debian-dsa1571.en.html
Re: mount /usr
On 2014-06-05, Pieter Verberne wrote: >>> /dev/sd0a on /usr type ffs (local) > > I was thinking about a way out if this. I was remote at that moment. > It's funny because the only way out is to pull the power cable. A SSH > session was still up but I was logged in as a regular user. su and sudo > are not working since they are under /usr . Console is not able to > login. I put wheel users in group operator, too, so they can just run shutdown(8). > Maybe ACPI shutdown would work, Yeah, I was going to say, just hit the power button for a regular shutdown... > but it is a Soerkis. ... but I see the problem. Oh, and I'll reiterate that shadowing a filesystem with another is a valid and occasionally useful usage case. For instance, I regularly run a base system "make build" on one machine, then NFS-mount its /usr/obj over the local one on a sister machine and run "make install" there again. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: new OpenSSL flaws
> Now you have and example of how they are unwilling to work with you next > time someone asks why not work with OpenSSL on fixing it. Pretty direct > proof. The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE. We believe in peer review; they don't give a sh*t about it (as shown less than a month ago by the way their #3317 bug was fixed, commiting a different fix from the proposed one and introducing a stupid *and obvious* bug in the process - which got fixed the next day after otto@ mentioned it to the OpenSSL developers). If you can't trust people to apply one-liner fixes correctly, can you trust them for anything serious? Miod
Re: new OpenSSL flaws
On 6/5/2014 3:27 PM, Theo de Raadt wrote: Unfortunately I find myself believing reports that the OpenSSL people intentionally asked others for quarantine, and went out of their way to ensure this information would not come to OpenBSD and LibreSSL. There, I've said it. Now you have and example of how they are unwilling to work with you next time someone asks why not work with OpenSSL on fixing it. Pretty direct proof. --Kurt
Re: new OpenSSL flaws
Em 05-06-2014 16:27, Theo de Raadt escreveu: > There are two main open-source processes for dealing with discovery of > security issues and disclosure of that information to the greater > community. > > - One common process is that generally followed by OpenBSD. In this > proocess a bug is found, and a fix is commited as soon as the > improvement is known to good. Then if an asssement has been done, and > it is determined to be important, disclosure occurs, of course after > the commit is already public. Everyone including the vendors had the > opportunity to get the information in a fair and equal way. > > - The other main process used by some open source groups, is to > quarantine important repairs. A fix is firsst disclosed all affected > parties, or at least the right concerned subset. This creates a delay > before information availability, but the coordination is intended to > provide a benefit. Everyone generally gets the information in a fair > and equal way. > > Both processses have their place. Each software group has their own > limitations and needs which will drive their selection. > > > Is clear that the second process -- intending to also take an ethical > path for disclosure -- should not specifically exclude a part of the > community. > > > Unfortunately I find myself believing reports that the OpenSSL people > intentionally asked others for quarantine, and went out of their way > to ensure this information would not come to OpenBSD and LibreSSL. > > There, I've said it. That's exactly my though. Specially, because FreeBSD and NetBSD were warned, but not OpenBSD. If this was only a rant or any childish behavior from them, it's something stupid and, of course, not the right thing to do. But hey, we're all human. My real concern is if this something else, a hidden agenda, in that this "stupid disclosure" was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
There are two main open-source processes for dealing with discovery of security issues and disclosure of that information to the greater community. - One common process is that generally followed by OpenBSD. In this proocess a bug is found, and a fix is commited as soon as the improvement is known to good. Then if an asssement has been done, and it is determined to be important, disclosure occurs, of course after the commit is already public. Everyone including the vendors had the opportunity to get the information in a fair and equal way. - The other main process used by some open source groups, is to quarantine important repairs. A fix is firsst disclosed all affected parties, or at least the right concerned subset. This creates a delay before information availability, but the coordination is intended to provide a benefit. Everyone generally gets the information in a fair and equal way. Both processses have their place. Each software group has their own limitations and needs which will drive their selection. Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. Unfortunately I find myself believing reports that the OpenSSL people intentionally asked others for quarantine, and went out of their way to ensure this information would not come to OpenBSD and LibreSSL. There, I've said it.
Re: new OpenSSL flaws
Em 05-06-2014 15:57, Theo de Raadt escreveu: >> Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu: >>> We are sorry that the errata for these libssl security issues are not >>> up yet. >>> >>> The majority of these issues are in our ssl library as well. >>> >>> Most other operating system vendors have patches available, but that >>> is because they were (obviously) given a heads up to prepare them over >>> the last few days. >>> >>> OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. >>> >>> >>> >>> So hold on, we'll try to have errata out in a few hours. >>> >> Theo, >> >> I'm just curious, but, this happened in the past? > Sure, it has happened in the past. But probably not to this > degree. > > Some sort of timeline has been published. Read between the lines. > > http://seclists.org/oss-sec/2014/q2/466 Hmmm, the first thing I did on that page was ctrl + f OpenBSD: not found. It's very interesting that this happened, to this degree as you mentioned, just after you guys forked OpenSSL. I've disable most of the daemons that use ssl in my systems, until this errata comes along. Don't hush it, specially since you guys didn't got notified of this. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
> Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu: > > We are sorry that the errata for these libssl security issues are not > > up yet. > > > > The majority of these issues are in our ssl library as well. > > > > Most other operating system vendors have patches available, but that > > is because they were (obviously) given a heads up to prepare them over > > the last few days. > > > > OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. > > > > > > > > So hold on, we'll try to have errata out in a few hours. > > > Theo, > > I'm just curious, but, this happened in the past? Sure, it has happened in the past. But probably not to this degree. Some sort of timeline has been published. Read between the lines. http://seclists.org/oss-sec/2014/q2/466
Re: new OpenSSL flaws
Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu: > We are sorry that the errata for these libssl security issues are not > up yet. > > The majority of these issues are in our ssl library as well. > > Most other operating system vendors have patches available, but that > is because they were (obviously) given a heads up to prepare them over > the last few days. > > OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. > > > > So hold on, we'll try to have errata out in a few hours. > Theo, I'm just curious, but, this happened in the past? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: CPU power consumption on thinkpad x201 on openbsd current
On Thu, Jun 05, 2014 at 10:53:38AM +0200, Johan Svensson wrote: > On 06/05/14 00:53, STeve Andre' wrote: > >On 06/04/14 17:08, Johan Svensson wrote: > >>I'm trying to migrate from Linux to Openbsd on my laptop > >>(thinkpad x201). > >> > >>The first problem that i came across was that the Cpu fanspeed > >>was running constantly at 3500RPM. > >>After the acpithinkpad.c patch from jcs (and i modified to make > >>it work on the openbsd-current(link: > >>http://exclude.se/patch/jcs_mod_by_js.diff) > >> > >>Another thing that i noticed is that the battery lifetime is really bad. > >>In Linux i get around ~5,5 hours. > >>In OpenBSD i get around 2 hours. > >> > >>when i ran : sysctl hw.sensors | grep -i consumption. > >>the output of the cpu was 6W. > >> > >>in Linux it's around 1,5W. > >> > >>with: apmd -C and apmd -L it's the same. > >>dmesg: http://exclude.se/openbsd/dmesg.txt > >> > >>Is there anyway to fix this? > >> > >>Regards > >>Johan Svensson > >> > >> > >Take a look at hw.setperf in sysctl. I think you are running at the > >maximum cpu speed? On my 2.8GHz W500 I can run at 800, 1600, > >2133 and 2801. 800MHz makes a huge difference. You have to > >try different values for setperf to see what happens. sysctl will > >also tell you the speed in hw.cpuspeed. > > > >--STeve Andre' > This my output from sysctl and apm when running on the lowest clockspeed: > # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" > hw.sensors.acpithinkpad0.fan0=1959 RPM > hw.sensors.itherm0.power0=6.00 W (CPU power consumption) > hw.cpuspeed=1199 > hw.setperf=0 > # apm > Battery state: high, 70% remaining, 111 minutes life estimate > A/C adapter state: not connected > Performance adjustment mode: manual (1199 MHz) > > > This is the output when i use apm -H: > # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" > hw.sensors.acpithinkpad0.fan0=1972 RPM > hw.sensors.itherm0.power0=6.00 W (CPU power consumption) > hw.cpuspeed=2666 > hw.setperf=100 > # apm > Battery state: high, 68% remaining, 107 minutes life estimate > A/C adapter state: not connected > Performance adjustment mode: manual (2666 MHz) > > The energy consumption is the same which is odd. > > --Johan > This may be a bug in itherm(4), I'll take a look.
new OpenSSL flaws
We are sorry that the errata for these libssl security issues are not up yet. The majority of these issues are in our ssl library as well. Most other operating system vendors have patches available, but that is because they were (obviously) given a heads up to prepare them over the last few days. OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. So hold on, we'll try to have errata out in a few hours.
Re: mount /usr
On June 5, 2014 6:56:42 PM CEST, Pieter Verberne wrote: >On 2014-06-05 18:25, Alexander Hall wrote: >> On June 5, 2014 2:26:44 PM CEST, Pieter Verberne >> wrote: >>> $ mount >>> /dev/wd0a on / type ffs (NFS exported, local, noatime, softdep) >>> /dev/wd0d on /usr type ffs (local, noatime, nodev, softdep) >>> /dev/wd1a on /home type ffs (NFS exported, local, nodev, nosuid) >>> /dev/sd0a on /usr type ffs (local) >>> $ >>> >>> oops... >>> >>> :-) >> >> Well, yes, you mounted sd0a on top of wd0d. Possibly not what you >> intended, but fully valid. Out is there some major oops I'm missing? >> O_o > >I was thinking about a way out if this. I was remote at that moment. >It's funny because the only way out is to pull the power cable. A SSH >session was still up but I was logged in as a regular user. su and sudo > >are not working since they are under /usr . Console is not able to >login. > >Maybe ACPI shutdown would work, but it is a Soerkis. > >Auch. Heh. Indeed a tricky situation then. :)
Re: mount /usr
On 2014-06-05 18:25, Alexander Hall wrote: On June 5, 2014 2:26:44 PM CEST, Pieter Verberne wrote: $ mount /dev/wd0a on / type ffs (NFS exported, local, noatime, softdep) /dev/wd0d on /usr type ffs (local, noatime, nodev, softdep) /dev/wd1a on /home type ffs (NFS exported, local, nodev, nosuid) /dev/sd0a on /usr type ffs (local) $ oops... :-) Well, yes, you mounted sd0a on top of wd0d. Possibly not what you intended, but fully valid. Out is there some major oops I'm missing? O_o I was thinking about a way out if this. I was remote at that moment. It's funny because the only way out is to pull the power cable. A SSH session was still up but I was logged in as a regular user. su and sudo are not working since they are under /usr . Console is not able to login. Maybe ACPI shutdown would work, but it is a Soerkis. Auch.
Re: mount /usr
On June 5, 2014 2:26:44 PM CEST, Pieter Verberne wrote: >$ mount >/dev/wd0a on / type ffs (NFS exported, local, noatime, softdep) >/dev/wd0d on /usr type ffs (local, noatime, nodev, softdep) >/dev/wd1a on /home type ffs (NFS exported, local, nodev, nosuid) >/dev/sd0a on /usr type ffs (local) >$ > >oops... > >:-) Well, yes, you mounted sd0a on top of wd0d. Possibly not what you intended, but fully valid. Out is there some major oops I'm missing? O_o /Alexander
Re: pf anchor references
On Mon, Jun 02, 2014 at 17:51 +0200, Mike Belopuhov wrote:
> Hi,
>
> I've been chasing some bugs in the pfctl anchor code for a couple
> of weeks and I'm not astonished at how loose the handling is in
> general. Lot's of rules and checks are being violated by some
> code paths while honoured by others. The problem I have is that
> it's truly a rabbit's hole: almost every bug I hit is a feature
> in disguise.
>
> One thing that I particularly hate is called an anchor reference.
> A good example of this is a ruleset like this:
>
> anchor "foo" {
> block all
> }
> anchor "foo"
>
> If you believe it should be a syntax error let me disappoint you.
> The second 'anchor "foo"' is just a reference to the anchor named
> "foo" defined before:
>
> # echo -e 'anchor "foo" {\n block all\n}\nanchor "foo"' | pfctl -f -
> # pfctl -a '*' -sr
> anchor "foo" all {
> block drop all
> }
> anchor "foo" all {
> block drop all
> }
> # echo -e 'pass all' | pfctl -a 'foo' -f -
> # pfctl -a '*' -sr
> anchor "foo" all {
> pass all flags S/SA
> }
> anchor "foo" all {
> pass all flags S/SA
> }
>
> And to demonstrate a reference specified by an absolute path we can
> add anchor "/foo" inside "foo":
>
> # echo -e 'anchor "/foo"' | pfctl -a 'foo' -f -
>
> This obviously gets us an endless loop if we decide to print out
> contents recursively (pfctl -a '*' -sr). Thankfully this doesn't
> affect ruleset evaluation in the kernel.
>
> The basic question I have is why do we need this dangerous and (at
> least in my eyes) pretty useless mechanism?
>
> Any opinions on this? Does anyone make any sensible use of it?
> Should we try to simplify this by removing ambiguous functionality?
>
> Cheers,
> Mike
While I've got a few responses on tech supporting me, I should
probably ask misc@ as well for additional scrutiny. And besides,
I've come up with an example that might simplify ruleset creation
for say multiple customer vlans or rdomains. Does anyone use it
like that? This looks like an anchor template that we want to
specify but not use directly in the main ruleset, but it plays
somewhat nicely with "quick" anchors.
(The ruleset below was tested and works correctly)
Cheers,
Mike
block all
anchor "customer1" quick on rdomain 1 {
anchor "/allow-egress"
anchor "/allow-ssh"
anchor "/allow-icmp-echo"
}
anchor "customer2" quick on rdomain 2 {
anchor "/allow-egress"
anchor "/allow-ssh"
}
pass in quick on rdomain 0 proto tcp to (self) port ssh
pass out quick on rdomain 0
# end of ruleset evaluation
block quick
anchor "allow-ssh" {
pass in proto tcp to (self) port ssh
}
anchor "allow-icmp-echo" {
pass in inet proto icmp to (self) icmp-type echoreq code 0
}
anchor "allow-egress" {
pass out
}
mount /usr
$ mount /dev/wd0a on / type ffs (NFS exported, local, noatime, softdep) /dev/wd0d on /usr type ffs (local, noatime, nodev, softdep) /dev/wd1a on /home type ffs (NFS exported, local, nodev, nosuid) /dev/sd0a on /usr type ffs (local) $ oops... :-)
New OpenSSL advisory
Just a notice: there is a new OpenSSL advisory, at https://www.openssl.org/news/secadv_20140605.txt. Reproduced below for your convenience. (No word on the degree to which LibreSSL is vulnerable.) === OpenSSL Security Advisory [05 Jun 2014] SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Jüri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Gröbert and Ivan Fratrić at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack" Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with addit
Re: CPU power consumption on thinkpad x201 on openbsd current
On 2014-06-05 11:09, David Coppa wrote: On Thu, Jun 5, 2014 at 10:53 AM, Johan Svensson wrote: This my output from sysctl and apm when running on the lowest clockspeed: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1959 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=1199 hw.setperf=0 # apm Battery state: high, 70% remaining, 111 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (1199 MHz) This is the output when i use apm -H: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1972 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=2666 hw.setperf=100 # apm Battery state: high, 68% remaining, 107 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (2666 MHz) The energy consumption is the same which is odd. Are you running with the latest bios (1.40-1.15) from Lenovo? Yes it is the latest bios. Hmmm. Smells like a bug, to me. But by changing hw.setperf your self you should be able to go to other speeds(?). And of course, the real test is to see if you get longer life at setperf 0. --STeve Andre' # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" && apm hw.sensors.acpithinkpad0.fan0=1965 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=1199 hw.setperf=0 Battery state: high, 57% remaining, 91 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (1199 MHz) # It seems like that's the same output. If the processor throttles down it should also consume less energy, but it says 6W all the time though.
OpenSMTPD force TLS issues
I encountered two problems with snmpd when trying to force TLS connections. First a documentation issue. The man 5 snmpd.conf states relay options would be: | relay [backup [mx]] [as address] [source address] [hostname name] | [hostnames names] [pki pkiname] [tls | verify] [..] | Note that the tls and verify options are mutually | exclusive In fact, "verify" does not work in 5.5, but one needs to add "tls verify" to the "relay" (not "relay via") statement. I.e. the manpage should indeed show "[tls [verify]]". The second issue is with "listen on". The options "tls-require" and "secure" seem to be ignored there. Any suggestions? Cheers David -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: CPU power consumption on thinkpad x201 on openbsd current
On Thu, Jun 5, 2014 at 10:53 AM, Johan Svensson wrote: > This my output from sysctl and apm when running on the lowest clockspeed: > # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" > hw.sensors.acpithinkpad0.fan0=1959 RPM > hw.sensors.itherm0.power0=6.00 W (CPU power consumption) > hw.cpuspeed=1199 > hw.setperf=0 > # apm > Battery state: high, 70% remaining, 111 minutes life estimate > A/C adapter state: not connected > Performance adjustment mode: manual (1199 MHz) > > > This is the output when i use apm -H: > # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" > hw.sensors.acpithinkpad0.fan0=1972 RPM > hw.sensors.itherm0.power0=6.00 W (CPU power consumption) > hw.cpuspeed=2666 > hw.setperf=100 > # apm > Battery state: high, 68% remaining, 107 minutes life estimate > A/C adapter state: not connected > Performance adjustment mode: manual (2666 MHz) > > The energy consumption is the same which is odd. Are you running with the latest bios (1.40-1.15) from Lenovo?
Re: CPU power consumption on thinkpad x201 on openbsd current
On 06/05/14 04:53, Johan Svensson wrote: On 06/05/14 00:53, STeve Andre' wrote: On 06/04/14 17:08, Johan Svensson wrote: I'm trying to migrate from Linux to Openbsd on my laptop (thinkpad x201). The first problem that i came across was that the Cpu fanspeed was running constantly at 3500RPM. After the acpithinkpad.c patch from jcs (and i modified to make it work on the openbsd-current(link: http://exclude.se/patch/jcs_mod_by_js.diff) Another thing that i noticed is that the battery lifetime is really bad. In Linux i get around ~5,5 hours. In OpenBSD i get around 2 hours. when i ran : sysctl hw.sensors | grep -i consumption. the output of the cpu was 6W. in Linux it's around 1,5W. with: apmd -C and apmd -L it's the same. dmesg: http://exclude.se/openbsd/dmesg.txt Is there anyway to fix this? Regards Johan Svensson Take a look at hw.setperf in sysctl. I think you are running at the maximum cpu speed? On my 2.8GHz W500 I can run at 800, 1600, 2133 and 2801. 800MHz makes a huge difference. You have to try different values for setperf to see what happens. sysctl will also tell you the speed in hw.cpuspeed. --STeve Andre' This my output from sysctl and apm when running on the lowest clockspeed: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1959 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=1199 hw.setperf=0 # apm Battery state: high, 70% remaining, 111 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (1199 MHz) This is the output when i use apm -H: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1972 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=2666 hw.setperf=100 # apm Battery state: high, 68% remaining, 107 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (2666 MHz) The energy consumption is the same which is odd. --Johan Hmmm. Smells like a bug, to me. But by changing hw.setperf your self you should be able to go to other speeds(?). And of course, the real test is to see if you get longer life at setperf 0. --STeve Andre'
Re: CPU power consumption on thinkpad x201 on openbsd current
On 06/05/14 00:53, STeve Andre' wrote: On 06/04/14 17:08, Johan Svensson wrote: I'm trying to migrate from Linux to Openbsd on my laptop (thinkpad x201). The first problem that i came across was that the Cpu fanspeed was running constantly at 3500RPM. After the acpithinkpad.c patch from jcs (and i modified to make it work on the openbsd-current(link: http://exclude.se/patch/jcs_mod_by_js.diff) Another thing that i noticed is that the battery lifetime is really bad. In Linux i get around ~5,5 hours. In OpenBSD i get around 2 hours. when i ran : sysctl hw.sensors | grep -i consumption. the output of the cpu was 6W. in Linux it's around 1,5W. with: apmd -C and apmd -L it's the same. dmesg: http://exclude.se/openbsd/dmesg.txt Is there anyway to fix this? Regards Johan Svensson Take a look at hw.setperf in sysctl. I think you are running at the maximum cpu speed? On my 2.8GHz W500 I can run at 800, 1600, 2133 and 2801. 800MHz makes a huge difference. You have to try different values for setperf to see what happens. sysctl will also tell you the speed in hw.cpuspeed. --STeve Andre' This my output from sysctl and apm when running on the lowest clockspeed: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1959 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=1199 hw.setperf=0 # apm Battery state: high, 70% remaining, 111 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (1199 MHz) This is the output when i use apm -H: # sysctl hw | grep -iE "cpuspeed|setperf|fan|consumption" hw.sensors.acpithinkpad0.fan0=1972 RPM hw.sensors.itherm0.power0=6.00 W (CPU power consumption) hw.cpuspeed=2666 hw.setperf=100 # apm Battery state: high, 68% remaining, 107 minutes life estimate A/C adapter state: not connected Performance adjustment mode: manual (2666 MHz) The energy consumption is the same which is odd. --Johan
