Re: Virtual firewalls with OpenBSD and PF
..and a way to have it revert in 2 minutes unless the operator does something, for the times when you cut off the branch you are sitting on. 2014-04-09 23:55 GMT+02:00 Adam Thompson athom...@athompso.net: I should add that once using source control abs a script to manage edits to pf.conf, it is easy to use at(1) to simulate Juniper's commit confirmed feature, adding another level of safety. -Adam On April 9, 2014 7:50:14 AM CDT, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 09-04-2014 06:31, Stuart Henderson escreveu: On 2014-04-08, Giancarlo Razzolini grazzol...@gmail.com wrote: If you're going to script this, you could have it make a copy of the file and work on that, so an unexpected reboot won't leave you with a pf.conf that may have errors. For even more safety, you could reload the ruleset using a copy of the file, leaving /etc/pf.conf with the old rules so that the most you need to do to recover from fat-finger accidents is reboot (and then you can copy the new file back out to pf.conf after it's been proven). I take a different approach and make sure I have out-of-band console access :) I would strongly encourage keeping pf.conf in source control though. Something as simple as rcs on the box itself is a huge step up from just editing the file directly, though I prefer to have them on a separate machine (I use svn for that). I use git and my script edit the source control version, not /etc one. So if the syntax check passes, my script automatically copies the pf.conf to /etc and asks if I want to commit and push the new version. Of course the script above won't help with rules that are right in its syntax, but are passing or blocking traffic they were not meant to. I found empirically that the majority of the mistakes are in pf's syntax. When you make a wrong rule you'll either detect it right away, for instance, a block rule that blocks the wrong traffic or you will not detect it for a long time. Hmm.. It is often fairly quick to pick up rules which over-block (though problems with jobs which only occur weekly or monthly can take a while to track down, and also there are situations where you won't notice a problem until all firewall states are flushed and all tables flushed and reloaded). But it's a lot harder to pick up rules which are too open. Exactly. That's why I use policy (tags) based firewalling. I makes a little easier to pick up on such errors. Also, even when detecting an unexpected behavior, it might be hard to pinpoint where it is in you pf configuration. I had to use tags many times to discover that the combination of 3 or more rules was causing the unexpected behavior. match log(matches) is extremely useful here. Exactly. Matching and logging is very nice, because it is sticky and you can log the entire flow of a packet with it. Speaking of flows, I use pflow with nfsense and it helps a lot in detecting these too open rules. Because there are these weekly or daily jobs that sometimes can't be run ahead of time and you won't need to wait until they run again, just take a look at the flows in nfsen. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- May the most significant bit of your life be positive.
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
Hi, Steve Quinn wrote: I have been recently playing with OpenBSD. I am very impressed with the whole experience, great job people !! I am using an HP nc6320 Laptop. Quite often, I get an error similar to this with amd64 5.4 and 5.5 acpitz3: critical temperature exceeded 3786C, shutting down If that temperature were to be correct, your Silicon would be liquid or possibly even gaseous :) I had a nc6120 and there was an ACPI bug very similar to this, solved with 5.3, if I remember correctly. Sadly, my hardware broke, so I cannot verify if it surfaced again. Riccardo
Re: Nonexistant domains resolve to my local domain
On 10-04-2014 05:51, Hugo Osvaldo Barrera wrote: On 2014-04-10 01:16, Giancarlo Razzolini wrote: Em 10-04-2014 00:43, Hugo Osvaldo Barrera escreveu: Hi, I've having this extremely wierd issue. My hostname is elysion.barrera.io. When I try to ping, curl, or something alike aDomainIReallySureDoeNotExist.com, it pings/curls/whatever my local domain. Maybe an example can me clearer: # ping adsfsdgasdadsfasfsdfasdf.net PING elysion.barrera.io (174.136.104.18): 56 data bytes 64 bytes from 174.136.104.18: icmp_seq=0 ttl=255 time=0.032 ms 64 bytes from 174.136.104.18: icmp_seq=1 ttl=255 time=0.081 ms dig, however, works fine: # dig adsfsdgasdadsfasfsdfasdf.net snip ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 20200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 snip I've tried changing nameserver to my ISP's, Google Public DNS, etc, the issue is always persistant (besides, dig working makes me think it's a local issue). Note that ALL nonexistant domain resolve to myself, never anything different. Any hints on where I should be looking? -- Hugo Osvaldo Barrera [demime 1.01d removed an attachment of type application/pgp-signature] You need to elaborate on a lot of things. We could only guess on who is to blame here (my money is on a misconfigured dns server either be a transparent dns proxy at your isp or wrongly configured one in your networl). Post your /etc/hosts, /etc/resolv.conf and dmesg for starters this is the initial information required for helping solving your issue. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC Any DNS traffic on port 53 when you ping a new nonexistant domain (i.e. how is ping resolving / who is it getting the IP from)?
Re: Nonexistant domains resolve to my local domain
Try ASR_DEBUG=1 ping somehost and post the result..
Re: Nonexistant domains resolve to my local domain
On 04/10/14 21:24, Zé Loff wrote: On 10-04-2014 05:51, Hugo Osvaldo Barrera wrote: On 2014-04-10 01:16, Giancarlo Razzolini wrote: Em 10-04-2014 00:43, Hugo Osvaldo Barrera escreveu: Hi, I've having this extremely wierd issue. My hostname is elysion.barrera.io. When I try to ping, curl, or something alike aDomainIReallySureDoeNotExist.com, it pings/curls/whatever my local domain. Maybe an example can me clearer: # ping adsfsdgasdadsfasfsdfasdf.net PING elysion.barrera.io (174.136.104.18): 56 data bytes 64 bytes from 174.136.104.18: icmp_seq=0 ttl=255 time=0.032 ms 64 bytes from 174.136.104.18: icmp_seq=1 ttl=255 time=0.081 ms Any DNS traffic on port 53 when you ping a new nonexistant domain (i.e. how is ping resolving / who is it getting the IP from)? Would ASR_DEBUG help in this case? http://marc.info/?l=openbsd-miscm=137908307611495w=2 $ ASR_DEBUG=1 ping nosuchdomainexistsok.com
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
On Thu, Apr 10, 2014 at 12:37 AM, Steve Quinn letter2st...@gmail.comwrote: Hi folks I have been recently playing with OpenBSD. I am very impressed with the whole experience, great job people !! Just one side note. Most (or all?) major operating systems are using implementation of ACPI from Intel, but OpenBSD has own implementation http://www.openbsd.org/cgi-bin/man.cgi?query=acpisektion=4apropos=0manpath=OpenBSD+Currentarch=i386, which may be sometimes problematic, but generally fixes are available very quickly compared to that general implementation. I am using an HP nc6320 Laptop. Quite often, I get an error similar to this with amd64 5.4 and 5.5 acpitz3: critical temperature exceeded 3786C, shutting down For me it was a nice error to get, because it introduced me to the coolness of using boot -c and config -e I have no problems working around the issue. I did some digging and see others with the same issue on similar hardware http://comments.gmane.org/gmane.os.openbsd.misc/176044 http://comments.gmane.org/gmane.os.openbsd.misc/205033 I'd like to offer the use of my HP nc6320 if a Developer would like to play directly with the hardware to assist others in the community with the issue. I'll be at BSDCan 2014 and can bring it along. Otherwise, please let me know if/how I can be of any help. Good quick start is to send dmesg output from latest -current (both i386 and amd64 IF there's some difference) and something which you probably already checked ; BIOS versions Take care Steve Quinn
Re: Nonexistant domains resolve to my local domain
It looks like a misconfigured split DNS to me, but that's just a wild-ass guess.
Re: Nonexistant domains resolve to my local domain
On 2014-04-10 00:43, Hugo Osvaldo Barrera wrote: Hi, I've having this extremely wierd issue. My hostname is elysion.barrera.io. When I try to ping, curl, or something alike aDomainIReallySureDoeNotExist.com, it pings/curls/whatever my local domain. Maybe an example can me clearer: # ping adsfsdgasdadsfasfsdfasdf.net PING elysion.barrera.io (174.136.104.18): 56 data bytes 64 bytes from 174.136.104.18: icmp_seq=0 ttl=255 time=0.032 ms 64 bytes from 174.136.104.18: icmp_seq=1 ttl=255 time=0.081 ms dig, however, works fine: # dig adsfsdgasdadsfasfsdfasdf.net snip ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 20200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 snip I've tried changing nameserver to my ISP's, Google Public DNS, etc, the issue is always persistant (besides, dig working makes me think it's a local issue). Note that ALL nonexistant domain resolve to myself, never anything different. Any hints on where I should be looking? -- Hugo Osvaldo Barrera I got a few off-list replies that led me to the issue. I've wildcard CNAME set up (which responds for any non-existant subdomain: *.barrera.io IN CNAME elysion.barrera.io. When resoling nonexistant.net fails, ping will seach for nonexistant.net.barrera.io. And, well, the rest of it is pretty obvious. So the issue wasn't on the nameserver I'm using to resolve, nor on my local system, but rather a combination of existing DNS rescords, and my search domain. I guess the solution is getting rid of the wildcard domain - any other alternatives? Thanks, -- Hugo Osvaldo Barrera [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Nonexistant domains resolve to my local domain
On 10.04.2014 13:41, Stuart Henderson wrote: Try ASR_DEBUG=1 ping somehost and post the result.. Very useful, where can we find informations about these kind of variables like LD_DEBUG, ASR_DEBUG or other ?? Thank you very much
Re: Nonexistant domains resolve to my local domain
On 2014/04/10 17:32, Wesley wrote: On 10.04.2014 13:41, Stuart Henderson wrote: Try ASR_DEBUG=1 ping somehost and post the result.. Very useful, where can we find informations about these kind of variables like LD_DEBUG, ASR_DEBUG or other ?? Thank you very much LD_DEBUG is mentioned in ld.so(1), some of the resolver environment variables are mentioned in resolv.conf(5), HOSTALIASES is mentioned in hostname(7), but there's no manpage that talks about ASR_DEBUG or ASR_CONFIG, you would need to read the source code to find those.
Re: Nonexistant domains resolve to my local domain
Em 10-04-2014 01:51, Hugo Osvaldo Barrera escreveu: As I mentioned before, I tried different nameservers including my ISPs and Google's Public DNS (so a misconfigured dns server is extremely unlikely). I didn't mention any transparent proxies because there aren't any either. Connection is straight to the public internet. /etc/hosts: ::1localhost 127.0.0.1 localhost 174.136.104.18 elysion.barrera.io /etc/resolv.conf: nameserver 208.79.88.7 nameserver 208.79.88.9 /etc/resolv.conf (another version): nameserver 8.8.8.8 Try running the www.dnsleaktest.com on that machine, if you can, to be sure that your ISP isn't transparently intercepting your dns requests. If they are, than that is most likely the culprit. They generally redirect the non existent domains to some page of theirs where they will show lots of ads. -- Giancarlo Razzolini GPG: 4096R/77B981BC
OpenBSD Foundation 2014 Fundraising Campaign.
The OpenBSD Foundation is happy to report that the $150,000 goal of the 2014 fundraising campaign has been reached. We wish to thank our contributors large and small. We will continue our fundraising efforts both in the current year and next year. The success of this year's effort has allowed the Foundation to reverse the recent decline in the support we were able to offer the OpenBSD project. The Foundation has been able to assume responsibility for funding more aspects of the project infrastructure, such as the server electricity bill. The Foundation is now able to support efforts underway to rebuild a significant part of the project server infrastructure. This included a few things that were, literally, rotting. 2014's slate of hackathons has been solidified, ensuring these critical events will continue to provide a stream of improvements to the OpenBSD and related projects. We would like to especially thank the contributors who have made commitments for continuing donations to the Foundation. Every recurring regular donation allows us to budget and plan more effectively. The Foundation will continue to strive to improve its financial resources, and hopes to be able to provide further support to the projects in the future. Please continue to contribute!
Re: OpenBSD Foundation 2014 Fundraising Campaign.
On Thu, Apr 10, 2014 at 8:23 PM, Bob Beck b...@openbsdfoundation.org wrote: The OpenBSD Foundation is happy to report that the $150,000 goal of the 2014 fundraising campaign has been reached. We wish to thank our contributors large and small. We will continue our fundraising efforts both in the current year and next year. The success of this year's effort has allowed the Foundation to reverse the recent decline in the support we were able to offer the OpenBSD project. The Foundation has been able to assume responsibility for funding more aspects of the project infrastructure, such as the server electricity bill. The Foundation is now able to support efforts underway to rebuild a significant part of the project server infrastructure. This included a few things that were, literally, rotting. 2014's slate of hackathons has been solidified, ensuring these critical events will continue to provide a stream of improvements to the OpenBSD and related projects. We would like to especially thank the contributors who have made commitments for continuing donations to the Foundation. Every recurring regular donation allows us to budget and plan more effectively. The Foundation will continue to strive to improve its financial resources, and hopes to be able to provide further support to the projects in the future. Please continue to contribute! Congratulations ! $200k as target next year :-) -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Re: FYA: http://heartbleed.com/
Theo de Raadt deraadt at cvs.openbsd.org writes: So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys. So maybe you're right. Maybe we should all have these protections. I know glibc has some, but I don't think it just crashes out if you malloc(16) and read 65000 bytes. It will if you're at top of heap (should I say top of brk() to sound like I know what I'm talking about?) and hit an unmapped page; but the heap is one continuous mapped region, and you'll wind up all over it. So most of OpenSSL isn't run on OpenBSD. We have appliances that are vulnerable--FortiNet stuff, SonicWall stuff. Lots of RedHat, Fedora, CentOS, SuSE, Ubuntu, Debian, whatever machines. Basically everyone's vulnerable. This vulnerability would have been found if, before release of 1.0.1, someone would have taken a packet analyzer to OpenSSL and tried this. Regardless of your OpenBSD special memory allocation leak condom, a bunch of data coming back when you should see 4 bytes says something is very wrong here. So we assume it wouldn't have been found. If we did anything to trigger the bug, it would crash on OpenBSD, in Theo's ideal world; as apparently nobody triggered the bug, it still would have not crashed on OpenBSD, in Theo's ideal world. (We'll pretend Theo's ideal world is limited to coding concerns in OpenSSL, and doesn't involve everyone running OpenBSD or an OpenBSD-like malloc() implementation.) The moment this went out, some blackhat may have secretly analyzed the diff between 1.0 and 1.0.1 and gone, Oh lol! Or maybe saw the new support for TLS Heartbeat and gone, Hey man, a new feature. I bet I can break it! Security researchers took until 1.0.1f to do this. Even ignoring the full disclosure, a responsible disclosure would have shifted distribution packages around immediately when the new code went up. Every distribution has a network of friends in every other distribution who are all hooking up with upstream developers so that they all know about security vulnerabilities before they're out. Every distribution packages a patched binary before upstream drops code. Every distribution is ready to throw that thing right up on the mirrors immediately, one second after the code release hits the upstream repositories. And several hours later, sysadmins start noticing there's a security update. Some of us patch immediately, in production. Some of us have to run through evaluation, risk analysis (this takes me, personally, between ten seconds and ten minutes), testing, then final roll-out. Some of us need an hour; some of us need weeks. We're already hours behind. Between blackhats maybe finding the bug and not saying anything, blackhats analyzing the bug between announcement and the sysadmin noticing, and blackhats analyzing the bug between sysadmins noticing and patching, you have this big window of maybe we were hacked, and we have no real way to tell. Congratulations: your Chief Information Security Engineer is Schrödinger's Cat. Your keys may have been stolen. Or not. You can patch quickly, but then you assume nobody has stolen your keys in the first hour or twelve that the exploit became known. So, no. Even if OpenSSL were developed responsibly by the standards of Theo, 99.999% of everything would still be vulnerable. Hell, even with Responsible Disclosure, our only reasonable response to this bug is to revoke and reissue 99.999% of all SSL certificates ever issued. And that's even considering just how much of a huge advantage responsible disclosure would have given us in terms of response time, as I've illustrated. This is not a situation where the programmers would have saved us all the headache by not tweaking away an OpenBSD protection. That was never a thing. Good PR for that protection--and maybe we should look at implementing it everywhere; I don't know, I don't understand it and thus can't analyze the risks or costs--but it's not something that, as a protection only available currently on OpenBSD, would have actually changed the situation. GMANE captcha: profiled
Re: FYA: http://heartbleed.com/
The moment this went out, some blackhat may have secretly analyzed the diff between 1.0 and 1.0.1 and gone, Oh lol! Or maybe saw the new support for TLS Heartbeat and gone, Hey man, a new feature. I bet I can break it! Security researchers took until 1.0.1f to do this. Even before heartbeat arrived, it would have crashed with the stupid openssl allocator turned off. Try it. Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Start nginx, put it under some heavy service. Look at the logs. See how bad things start to happen? Had the non-freelist code path been tested in OpenBSD OR ANYWHERE ELSE, it would have alerted the entire world that there are use-after-free's in other code paths. And the use-after-free's would have been fixed. They would not be able to hide. OpenSSL would have had a robust internal memory allocator. In the context of security software, robust means fail-hard, fail-closed, when any unexpected condition is triggered. That bad feature was added in 2006 and fully entrenched by 2008. More recently, the heartbeat feature was added, and if a hard system allocator was available, the initial testing would probably have exposed the problem right during the development cycle. Then it would have been fixed before deployment. But I think it is clear you aren't a programmer, and this is over your head. Or you are simply making excuses for others. Did they pay you to write all that text?
Re: FYA: http://heartbleed.com/
Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Yes but that's because OpenSSL is broken. If OpenSSL had not been broken in this respect, Segglemann's bug would not have survived any sort of testing or peer review. So no, fixing OpenSSL to work without its freelist would not necessarily have exposed heartbleed. John, there is bullshit coming out of your mouth.
Re: FYA: http://heartbleed.com/
Em 10-04-2014 15:22, Theo de Raadt escreveu: Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Yes but that's because OpenSSL is broken. If OpenSSL had not been broken in this respect, Segglemann's bug would not have survived any sort of testing or peer review. So no, fixing OpenSSL to work without its freelist would not necessarily have exposed heartbleed. John, there is bullshit coming out of your mouth. Oh my. Let us do a ssl library. Oh, it would be nice if we managed our own memory, you know, cause every library should manage their own memory. Why trust the operating system? After all it is not like it has being doing this forever. If more people use OpenBSD to develop and test things, I assure you that the world would be safer. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Smokeping on -current
On the last snapshot smokeping failed at startup. It fails even when I run it manually via rc.d script. $ sudo /etc/rc.d/smokeping -d start doing rc_read_runfile doing rc_check smokeping doing rc_pre doing rc_start Dropping privileges to _smokeping ... require Smokeping::probes::FPing failed: Can't locate IPC/Open3.pm: Permission denied at /usr/local/bin/../lib/Smokeping/probes/FPing.pm line 19, File line 113. BEGIN failed--compilation aborted at /usr/local/bin/../lib/Smokeping/probes/FPing.pm line 19, File line 113. Compilation failed in require at (eval 23) line 2, File line 113. doing rc_rm_runfile (failed) When I run it manually everything is OK. $ sudo smokeping Dropping privileges to _smokeping ... Note: logging to syslog as local0/info. Daemonizing /usr/local/bin/smokeping ... How can I debug it further? $ dmesg OpenBSD 5.5-current (GENERIC.MP) #38: Thu Apr 10 07:05:45 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (AuthenticAMD 686-class, 512KB L2 cache) 2.31 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,SSE3,CX16,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP real mem = 2129096704 (2030MB) avail mem = 2081837056 (1985MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/02/10, BIOS32 rev. 0 @ 0xf2030, SMBIOS rev. 2.4 @ 0xf (70 entries) bios0: vendor Phoenix Technologies, LTD version ASUS M2NPV-VM ACPI BIOS Revision 5005 date 06/02/2010 bios0: ASUSTek Computer INC. M2NPV-VM acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP MCFG APIC acpi0: wakeup devices HUB0(S5) XVRA(S5) XVRB(S5) XVRC(S5) UAR1(S5) UAR2(S5) PS2M(S4) PS2K(S4) USB0(S4) USB2(S4) AZAD(S5) MMAC(S5) MMCI(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (AuthenticAMD 686-class, 512KB L2 cache) 2.31 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,SSE3,CX16,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (HUB0) acpicpu0 at acpi0 acpicpu1 at acpi0 acpitz0 at acpi0: critical temperature is 75 degC acpibtn0 at acpi0: PWRB aibs0 at acpi0 RTMP RVLT RFAN aibs0: FSIF: misformed package: 3/5, assume 5 bios0: ROM list: 0xc/0xec00 0xd4000/0x1000 0xd5000/0x1000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) NVIDIA C51 Host rev 0xa2 at pci0 dev 0 function 0 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 2 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 3 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 4 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 5 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 6 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 7 not configured vga1 at pci0 dev 5 function 0 NVIDIA GeForce 6150 rev 0xa2 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) NVIDIA MCP51 Host rev 0xa2 at pci0 dev 9 function 0 not configured pcib0 at pci0 dev 10 function 0 NVIDIA MCP51 ISA rev 0xa3 nviic0 at pci0 dev 10 function 1 NVIDIA MCP51 SMBus rev 0xa3 iic0 at nviic0 spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5 spdmem1 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-5300CL5 iic1 at nviic0 NVIDIA MCP51 Memory rev 0xa3 at pci0 dev 10 function 2 not configured pciide0 at pci0 dev 13 function 0 NVIDIA MCP51 IDE rev 0xa1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: WDC WD800JB-00ETA0 wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) pciide1 at pci0 dev 14 function 0 NVIDIA MCP51 SATA rev 0xa1: DMA pciide1: using apic 4 int 20 for native-PCI interrupt pciide2 at pci0 dev 15 function 0 NVIDIA MCP51 SATA rev 0xa1: DMA pciide2: using apic 4 int 20 for native-PCI interrupt ppb0 at pci0 dev 16 function 0 NVIDIA MCP51 rev 0xa2 pci1 at ppb0 bus 1 em0 at pci1 dev 8 function 0 Intel 82540EM rev 0x02: apic 4 int 16, address 00:07:e9:10:32:a8 em1 at pci1 dev 9 function 0 Intel 82540EM rev 0x02: apic 4 int 17, address 00:07:e9:10:2a:20 pchb0 at pci0 dev 24 function 0 AMD AMD64 0Fh HyperTransport rev 0x00 pchb1 at pci0 dev 24 function 1 AMD
Re: FYA: http://heartbleed.com/
Maybe in your imaginary world where your malloc() library is a static code correctness analysis tool instead of a behavioral anomaly detection tool. The fact remains that this was a boundary error triggered by incorrect user input validation--that it would not crash under any circumstances where 100% of all OpenSSL code besides this very small block of code was 100% correct unless it was actively exploited. Normal heartbeats stay within correct bounds and function correctly: 100 bytes are allocated, the payload says it's 100 bytes, 100 bytes are read, no boundaries are exceeded. Apparently nobody did any testing or peer review that involved saying, Oh, shit. You actually send the length of a piece of user-supplied data WITH user-supplied data? I hope you're checking for any kind of stupid shit the user may do, like ask you to copy 5000 bytes of data into a 50 byte buffer and inject code, or something. If they did, they would have seen that they sent a 4 byte long heartbeat with a payload length of 10, and got back 10 bytes, and wondered where the hell 10 bytes came from. The range checking is happening inside dynamically allocated memory. I suspect Mr. Segglemann did run a simple test with all the sizes, but the daemon did not crash on him because the allocation scheme disables an increasingly common safetybelt for dynamically allocated memory. If he didn't do such a test, you would be the one calling him incompetent. This OpenBSD malloc safety belt is also included in many programming test tools. Surely someone ran those in the last two years. Unfortunately, the OpenSSL freelist foils them all, because inside the program full scope the objects remain live. You seem to understand bugs from the top down. But you don't understand that we can resist them from the bottom up, essentially free. Unless people overly complicate their own software to make security assessment impossible.
Re: FYA: http://heartbleed.com/
On Thu, Apr 10, 2014 at 4:18 PM, John Moser john.r.mo...@gmail.com wrote: Also why has nobody corrected me on this yet? I've read El Reg's analysis, and they missed a critical detail that I didn't see until I read the code in context: IT ALLOCATES TOO SMALL OF A WRITE BUFFER, TOO. Okay, it would send out the payload on exploit. It would also kill a heap canary that glibc should catch on free(). Christ maybe you're right. I'm looking at this again and I'm wrong: it DOES allocate big enough of a payload. Obviously I am not a programmer. There actually is no memory allocator bug in this code; it uses the allocator entirely correctly.
Re: Nonexistant domains resolve to my local domain
On 2014-04-10, Hugo Osvaldo Barrera h...@barrera.io wrote: I've wildcard CNAME set up (which responds for any non-existant subdomain: *.barrera.io IN CNAME elysion.barrera.io. ah. when people say not to use wildcard DNS records because they cause hard to debug problems, this is exactly what they're talking about ;)
PF for a VPS
Hi guys, I've rented a virtual private server with some friends and we would like to deploy a firewall. I suggested packet filter and OpenBSD because I have it at home, but really don't know about the performace of the OpenBSD packet filter into a virtual machine. The idea is to have some (6-9) different virtual machines running at the same time, 2 of then (apart from the firewall) will have a lot of incoming traffic and at least 1 will have a lot of outgoing network traffic, so my mates are thinking that PF into a virtual machine running OpenBSD is not going to have a good performance, maybe because (as far as I know) PF can't work using more than one core. Any of you have some experience about this? Could you give me some info about performance or some nice arguments to convince them? Thanks in advance! Excuse my english, but I don't practice it regularly.
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
On Thu, Apr 10, 2014 at 3:53 AM, Riccardo Mottola riccardo.mott...@libero.it wrote: If that temperature were to be correct, your Silicon would be liquid or possibly even gaseous :) :-) I noticed it would even boil a Titanium case ! http://www.chemicalelements.com/elements/ti.html I had a nc6120 and there was an ACPI bug very similar to this, solved with 5.3, if I remember correctly. Interesting, I'll try that out if necessary Sadly, my hardware broke, so I cannot verify if it surfaced again. Bummer. Thanks for sharing your experience with the issue Steve Quinn
Re: PF for a VPS
Sinosuke Noara capitan.shinc...@gmail.com wrote: Hi guys, I've rented a virtual private server with some friends and we would like to deploy a firewall. I suggested packet filter and OpenBSD because I have it at home, but really don't know about the performace of the OpenBSD packet filter into a virtual machine. The idea is to have some (6-9) different virtual machines running at the same time, 2 of then (apart from the firewall) will have a lot of incoming traffic and at least 1 will have a lot of outgoing network traffic, so my mates are thinking that PF into a virtual machine running OpenBSD is not going to have a good performance, maybe because (as far as I know) PF can't work using more than one core. That's true. PF doesn't work on more than one core. But I doubt that your VPS I/O will be able to saturate the one core-slice you get. Are all of these VPSs on the same physical machine? If so it seems best to run it on the host. That means no OpenBSD since OpenBSD will not host VMs. If they're not on the same machine then all the bouncing around the packets will do (especially going in and out on the same interface) will have a performance impact. Any of you have some experience about this? Could you give me some info about performance or some nice arguments to convince them? Thanks in advance! Excuse my english, but I don't practice it regularly. Looks better than some native speakers I know. - Martin
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
I had the same issue a couple of weeks ago with my Sager laptop. An update to a newer snapshot seemed to solve it. Sorry, I can't really offer any advice as the issue seemed to resolve on its own after the update and hasn't surfaced on any snapshots since then. Mike On Apr 9, 2014 4:37 PM, Steve Quinn letter2st...@gmail.com wrote: Hi folks I have been recently playing with OpenBSD. I am very impressed with the whole experience, great job people !! I am using an HP nc6320 Laptop. Quite often, I get an error similar to this with amd64 5.4 and 5.5 acpitz3: critical temperature exceeded 3786C, shutting down For me it was a nice error to get, because it introduced me to the coolness of using boot -c and config -e I have no problems working around the issue. I did some digging and see others with the same issue on similar hardware http://comments.gmane.org/gmane.os.openbsd.misc/176044 http://comments.gmane.org/gmane.os.openbsd.misc/205033 I'd like to offer the use of my HP nc6320 if a Developer would like to play directly with the hardware to assist others in the community with the issue. I'll be at BSDCan 2014 and can bring it along. Otherwise, please let me know if/how I can be of any help. Take care Steve Quinn
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
I had the same issue a couple of weeks ago with my Sager laptop. An update to a newer snapshot seemed to solve it. From time to time we have to explain this one. There is unknown and not yet understood bug, which we think is related to acpi EC handling. It seems to affect HP laptops more than others. It's been there since the beginning, so that would be 5+ years. There have been numerous efforts to fix it. For some reason it wanders around a bit. We've never actually managed to get one of the affected laptops into the hands of a serious developer who would hunt it down.
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
On Thu, Apr 10, 2014 at 7:31 AM, Tomas Bodzar tomas.bod...@gmail.com wrote: Just one side note. Most (or all?) major operating systems are using implementation of ACPI from Intel, but OpenBSD has own implementation http://www.openbsd.org/cgi-bin/man.cgi?query=acpisektion=4apropos=0manpath=OpenBSD+Currentarch=i386 , which may be sometimes problematic, but generally fixes are available very quickly compared to that general implementation. Wow, thanks for the great reference Good quick start is to send dmesg output from latest -current (both i386 and amd64 IF there's some difference) and something which you probably already checked ; BIOS versions Ok. Sounds great, thank you. I've yet to install -current and want to do it properly so it will be a few days until I have a dmesg to share Regarding the BIOS version, I will triple check but I'm usually quite anal about these things :-) Steve
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
On Thu, Apr 10, 2014 at 9:16 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: I had the same issue a couple of weeks ago with my Sager laptop. An update to a newer snapshot seemed to solve it. From time to time we have to explain this one. There is unknown and not yet understood bug, which we think is related to acpi EC handling. It seems to affect HP laptops more than others. It's been there since the beginning, so that would be 5+ years. There have been numerous efforts to fix it. For some reason it wanders around a bit. We've never actually managed to get one of the affected laptops into the hands of a serious developer who would hunt it down. Hi Theo I'd like to help in any way I can and hopefully get this bug squashed for good I have access to several of these HP models and can test locally, provide remote access or ship one if required Again, I'm from the Toronto area and am hitting my first BSDCan in May if that helps. Take care Steve Quinn
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
I have access to several of these HP models and can test locally, provide remote access or ship one if required Again, I'm from the Toronto area and am hitting my first BSDCan in May if that helps. A very helpful approach would be: 1. Find a few cheap machines that are 100% confirmed to have this issue repeatable. 2. Flood the ACPI subsystem developer community with them, by ninja action where you suddenly handcuff it to them at some conference, other evento, or even a pub. But please, I am exempt from this.
Re: # rm ../snapshots/i386/INSTALL.linux
nowadays in the days of UEFI, it is just plain wrong. that document will probably be deleted. On Thu, Apr 10, 2014 at 7:19 PM, Fung fungm...@qq.com wrote: out of sync? http://ftp.openbsd.org/pub/OpenBSD/snapshots/i386/INSTALL.linux
Re: PF for a VPS
On Fri, Apr 11, 2014 at 1:35 AM, Sinosuke Noara capitan.shinc...@gmail.comwrote: Hi guys, I've rented a virtual private server with some friends and we would like to deploy a firewall. I suggested packet filter and OpenBSD because I have it at home, but really don't know about the performace of the OpenBSD packet filter into a virtual machine. The idea is to have some (6-9) different virtual machines running at the same time, 2 of then (apart from the firewall) will have a lot of incoming traffic and at least 1 will have a lot of outgoing network traffic, so my mates are thinking that PF into a virtual machine running OpenBSD is not going to have a good performance, maybe because (as far as I know) PF can't work using more than one core. Any of you have some experience about this? Could you give me some info about performance or some nice arguments to convince them? Thanks in advance! Excuse my english, but I don't practice it regularly. 1) You don't mention which VPS are you planning to use 2) PF can handle a lot of traffic just fine, but you must test in YOUR scenario 3) You don't mention expected amount of traffic and type of that traffic 4) Why exactly are your friends against it? Maybe they don't know OpenBSD well, maybe VPS doesn't support OpenBSD and so on
Re: acpitz3: critical temperature exceeded with HP nc6320 Laptop
On Fri, Apr 11, 2014 at 3:18 AM, Steve Quinn letter2st...@gmail.com wrote: On Thu, Apr 10, 2014 at 7:31 AM, Tomas Bodzar tomas.bod...@gmail.com wrote: Just one side note. Most (or all?) major operating systems are using implementation of ACPI from Intel, but OpenBSD has own implementation http://www.openbsd.org/cgi-bin/man.cgi?query=acpisektion=4apropos=0manpath=OpenBSD+Currentarch=i386 , which may be sometimes problematic, but generally fixes are available very quickly compared to that general implementation. Wow, thanks for the great reference One correction I did not have single issue with ACPI over the years on Dell or Lenovo HW with OpenBSD, but had number of those with other BSDs, OpenSolaris or Linux with their Intel implementation. Especially cheaper consumer models from HP, Toshiba, Sony and similar has very interesting workarounds implemented to get it working at least somewhat even on Windows and Linux so these are often very funny :-) Good quick start is to send dmesg output from latest -current (both i386 and amd64 IF there's some difference) and something which you probably already checked ; BIOS versions Ok. Sounds great, thank you. I've yet to install -current and want to do it properly so it will be a few days until I have a dmesg to share Regarding the BIOS version, I will triple check but I'm usually quite anal about these things :-) Using -current is easy, just start with latest snapshot from mirror and use snapshot path for packages in PKG_PATH as well. From that time on easy like with regular system. Plus is you have binary upgrades to new snapshot mostly everyday (if you want to) - man sysmerge - checking current.html page IF some manual intervention needed - pkg_add -u . All of that takes like 15 minutes or so, depends on speed of your network and interval how often you will update between snapshots. Generally more stable then some so called stable/lts/whatever distros and you have latest fixes. For BIOS I meant if there's something related to ACPI in fixes from vendor. Steve
