OpenBSD 6.2 Released

Although US-CERT show network exploitable vulnerabilities in the base in the past couple of months, and rated like 9.5.

Can you provide the link for those? My google search only had 2 hits for US-cert and OpenBSD in 2017 Hit 1 and Hit 2.

In the second link
openbsd -- openbsd The mmap extension __MAP_NOFAULT in OpenBSD 5.8 and 5.9 allows attackers to cause a denial of service (kernel panic and crash) via a large size value. 2017-03-07 4.9 CVE-2016-6239
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd OpenBSD 5.8 and 5.9 allows local users to cause a denial of service (assertion failure and kernel panic) via a large ident value in a kevent system call. 2017-03-07 4.9 CVE-2016-6242
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd thrsleep in kern/kern_synch.c in OpenBSD 5.8 and 5.9 allows local users to cause a denial of service (kernel panic) via a crafted value in the tsp parameter of the __thrsleep system call. 2017-03-07 4.9 CVE-2016-6243
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd OpenBSD 5.8 and 5.9 allows local users to cause a denial of service (kernel panic) via a large size in a getdents system call. 2017-03-07 4.9 CVE-2016-6245
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd OpenBSD 5.8 and 5.9 allows certain local users with kern.usermount privileges to cause a denial of service (kernel panic) by mounting a tmpfs with a VNOVAL in the (1) username, (2) groupname, or (3) device name of the root node. 2017-03-07 4.9 CVE-2016-6246
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd OpenBSD 5.8 and 5.9 allows certain local users to cause a denial of service (kernel panic) by unmounting a filesystem with an open vnode on the mnt_vnodelist. 2017-03-07 4.9 CVE-2016-6247
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd OpenBSD 5.8 and 5.9 allows local users to cause a denial of service (NULL pointer dereference and panic) via a sysctl call with a path starting with 10,9. 2017-03-07 4.9 CVE-2016-6350
CONFIRM
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID(link is external)
openbsd -- openbsd Integer overflow in the uvm_map_isavail function in uvm/uvm_map.c in OpenBSD 5.9 allows local users to cause a denial of service (kernel panic) via a crafted mmap call, which triggers the new mapping to overlap with an existing mapping. 2017-03-07 4.9 CVE-2016-6522
CONFIRM
MLIST(link is external)
MLIST(link is external)
BID
Version 5.9 and earlier were no longer supported in 2017. Since they did not show up in 6.0/6.1 can we assume that they were addressed in a timely fashion?
 
008: SECURITY FIX: May 19, 2017 All architectures
An additional mitigation is added by placing a gap of 1 MB between the stack and mmap spaces.
A source code patch exists which remedies this problem.
It was patched, with an additional mitigation, in May.

The dates of the US-CERTS/CVE:
CVE Dictionary Entry:
CVE-2017-1000372
Original release date:
06/19/2017
Last revised:
06/29/2017
Source:
US-CERT/NIST
So much for secure by default.
Nothing is secure by default - it takes effort and in this particular case is was a proactive effort.
 
Must bite tongue ... must not enter into religious war ...

Let me put it this way: I have used FreeBSD, OpenBSD, and oodles and oodles of Linux (in addition to many non-open systems). I still use FreeBSD voluntarily, and I would have no problem using OpenBSD if I had a need for a second machine. I will only use Linux if someone pays me for it (perhaps with the exception of the Raspberry Pi, where FreeBSD is being a little ornery, and I may switch to Raspbian for simplicity). I think OpenBSD is a fine operating system, with a different focus.
 
Must bite tongue ... must not enter into religious war ...
I will only use Linux if someone pays me for it (perhaps with the exception of the Raspberry Pi, where FreeBSD is being a little ornery, and I may switch to Raspbian for simplicity).
There's a good use for Linux: if you need a live operating system to set up a network, where you can't from the operating system on that computer. Puppy Linux is suitable for that.
I think OpenBSD is a fine operating system, with a different focus.
It is good to have programs that are rebuilt, like security/libressl, where the full operating system and everything in its ports is expected to work with it. I'm more concerned about what gets contributed from OpenBSD to FreeBSD, such as PF.
 
Must bite tongue ... must not enter into religious war ...
I think OpenBSD is a fine operating system, with a different focus.

Thank you! I also think that FreeBSD is a fine operating system! Each to his/her own. Use the OS that meets your needs.
 
Any interesting changes and/or improvements you encountered?

An easily perused list is here

For me the big items are
  • The inteldrm(4) driver was updated to code based on Linux 4.4.70 - it now supports Skylake, Kaby Lake, and Cherryview devices and has better support for Broadwell and Valleyview devices.
  • dhclient(8) improvements:
  • The i386 and amd64 platforms have switched to using clang(1) as the base system compiler.
  • LibreSSL 2.6.3 even after enormous amouts of OpenSSL was removed it works seamlessly
  • Gnome 3.24
 
Any interesting changes and/or improvements you encountered?
Depends what you care about. The easier question would be what has not changed at all and what are the things that suck?

While complete disk encryption and installing to a RAID 1 (mirror) is trivial thanks to softraid the matter of the fact remains that OpenBSD still uses fdisk Master Boot Record (MBR) partitions and lacks the full proper support for GPT (there is GPT switch in fdisk for UEFI installation which works really well) let alone something like GEOM. More importunately OpenBSD still lacks a modern file system (WAPBL for embedded/root partition or HAMMER for storage). The guy who started bringing WAPBL from BitRig port of WAPBL of NetBSD completely disappeared. I would not contemplating running OpenBSD NFS server but even the NFS client is supper slow (I am using at home with DragonFly NFS server which is blazingly fast). Still GNU binutils crap in the base. Unfortunately you can still run Gnome crap on OpenBSD. Hopefully will be pruned soon from the ports three.

Having said that if you think of OpenBSD as an OS focused on correctness, security, and network I think the changes are spectacular. My favorite changes/new features (please refer to the link for the description) are KARL, trapsleds, and freezero. Network performance has improved spectacularly and we are very close to the point when entire network stack, PF, OpenBGPD will work without big giant lock and in supper optimized multiprocessor mode. Almost entire system is now pledged including many super complicated user-land programs like Chrome web browser.

As you know OpenBSD is the reference platform for among other things OpenSSH, LibreSSL, OpenSMTPd, OpenBGPD. Many changes improvements in those 4 I listed and some in mdoc. LibreSSL documentation is starting to look normal (people familiar with shitty OpenSSL documentation know what I am talking about)

Fewer bugs and security holes (hopefully) due to the switch to clang on amd64 and i386. Many small network daemons have being fixed or improved things like relayd and httpd for example. Too many improvements of native dhcp client and server to be able to summarise in one sentence.

Using Let's encrypt is super easy (built in tiny client).


From a casual desktop user point of view probably the most useful change is that syspatch is maturing really nicely. Even a major upgrade no longer requires sysmerge. Source patches for the stable branch are the thing of the past thanks to syspatch. Unfortunately no beadm ;) It looks like soon we will see similar way of upgrading stable packages between releases.



For people who care about ARM huge improvements. AMD64 and ARM are now what AMD64 and Sparc64 (32-bit sparc machines which SUN stopped selling 1989 were supported by SPARC port) used to be. You can genuinely use OpenBSD on ARM and I am contemplating buying my first ARM firewall. I am running OpenBSD on the EdgeRouter (mips octeon port) right now in my office protecting the Red Hat destktop from which I am typing.


I personally don't care much for native hypervisor. I think that it is a mistake and adds to a complexity and security vulnerability of the system but few developers had a high need for it so yes VMM works. OpenBSD runs in PV mode as DomU Xen as a champ so people who want to use OpenBSD on AWS infrastructure have nothing to fear.
 
Code:
$ uname -a
OpenBSD tengu 6.2 GENERIC.MP#0 amd64
 
Binutils' BSD replacement is ELF Tool Chain.

I'm not sure if this is what is in llvm: most of its binutils filename equivalents are prefixed with llvm-.

ELF Tool Chain is a different implementation than GNU devel/elfutils.
Unlike FreeBSD, OpenBSD runs really well on many different architectures and was never Wintel only OS (NetBSD heritage). Until the demise of Sun the default hacking platform was actaully sparc64 because it is big endian. Not that anything besides amd64, armv7, arm64, and octeon (mips64 for network hardware/switches) really matters these days. LLVM is the default compiler only on amd64 (sure on i386 as well but that is dead platform). On all other platforms one of old GCC versions is the default compiler. I think that might be the reason for keeping binutils crap for now in OpenBSD.
 
FreeBSD basically works on the Raspberry Pi (I have a Pi 3 right now, and will need to add a Pi Zero W).

Problem #1: Wireless does not work for my particular hardware. In one case, that's OK, because the first one is installed in a place where there is wired available, and wireless would be unreliable or non-existing. Unfortunately, I was thinking of using that one as a wireless AP (just for one or two clients, not production worthy, can be low performance), so scratch that nice additional feature. In the other case (the Pi Zero W), that's not OK, since (a) it has no wired connection, and (b) there is no wired ethernet nearby anyhow. All this could be fixed by throwing extra hardware at it (string more ethernet cable, or use USB-connected wireless), but that seems inelegant. Might also run out of USB ports.

Problem #2: From my little experimentation, it seems that to configure GPIO on FreeBSD to do "interesting" functions, you end up having to rebuild the kernel, which means setting up a cross-compilation environment. That's doable (Crochet and all that), but a lot of extra work. From reading web pages, it seems that on Raspbian that is not required.

In general, FreeBSD on the RPi seems to not be quite ready for prime time yet; too much is only "barely" or "basically" working, and there isn't critical mass for a community that has tried everything and keeps things going yet. In contrast, Raspbian seems to be heavily used and supported.

That's sad, because I'm very familiar and comfortable with administering *BSD, not so much with any Linux derivative. And because having to use Linux gives me hives, everything is getting so complex and overly integrated (need I say "systemd"?). On the other hand, if it ends up being less work to get Linux = Raspbian to work, I'm willing to deal with it. To me this is not a question of religious principles, just of practicalities.
 
That's sad, because I'm very familiar and comfortable with administering *BSD, not so much with any Linux derivative. And because having to use Linux gives me hives, everything is getting so complex and overly integrated (need I say "systemd"?). On the other hand, if it ends up being less work to get Linux = Raspbian to work, I'm willing to deal with it. To me this is not a question of religious principles, just of practicalities.
Maybe you have never tried the right Linux distro:) Hint: Alpine Linux
 
I am in the midst of an illness which keeps me from doing things right now. So, I will ask if anyone has yet tried this with an Intel 7260 dual channel card. On Linux on a 5 GHz network, I can get transfer speeds, on LAN, in the 20-40MBs range. With Open and FreeBSD, I'm only getting 2-3 MBs.

The 6.1 iwn man page says it does not support dual band haven't tried yet with 6.2. If I do this myself I will update but as mentioned, due to illness, this may take awhile and I apologize for asking others to check for me, but hope I've gained enough credit over the years to get away with it.
 
With Open and FreeBSD, I'm only getting 2-3 MBs.

I'm not sure why, but, I've found my WiFi signal to be sub-standard on OpenBSD 6.2. After I install the firmware for my atheros card I can usually wirelessly install all of the packages that I want. I've had lots of partial installs with OpenBSD 6.2. So now I install packages using my wired connection then revert back to my NIC afterwards.
Code:
OpenBSD bsd 6.2 GENERIC.MP#0 amd64
 
So, today I installed OpenBSD-6.2 on my yoga2. Unfortunately, no real improvements from the 6.1 snapshot I used last time, and I haven't even gotten X to start.
The thing I was more interested in, however, judging from release notes, was the iwn card. Unfortunately, still no more than 2-3 MBs on a LAN. The X stuff I'm sure I can solve when I feel a bit better,

Additionally, OpenBSD's iwn driver won't work on a hidden SSID, (Linux and FreeBSD do). Not a huge deal but if one hides their SSID it would have to be unhidden to work with OpenBSD.

Anyway, glad I got to test it. So, bottom line is that despite improvements on iwm driver, the dual channel card is still only giving 2-3MBs on 5GH network. I haven't really tested anything else, but that was the main reason I tried with this one.

Gosh, that sounds like I'm putting down the OpenBSD people, or something, hopefully, it's clear I'm not.
 
Gosh, that sounds like I'm putting down the OpenBSD people, or something, hopefully, it's clear I'm not.

I don't read it like that. I see your comments as objective observations. Now I'm running OpenBSD 6.2 on a work station (dual booted with Linux). I'm not running OpenBSD on my laptops due to the connectivity issues previously mentioned.
 
FreeBSD basically works on the Raspberry Pi (I have a Pi 3 right now, and will need to add a Pi Zero W).

Problem #1: Wireless does not work for my particular hardware. In one case, that's OK, because the first one is installed in a place where there is wired available, and wireless would be unreliable or non-existing
I think that Broadcom 43438 RPi3 comes with, is not well-supported by anything but Raspbian. Only Gentoo claims to provide a working ARM port for its driver. Yet Realtek-based Wifi dongles do not cost over 10€ and are barely 1x0,5 cm large. Might not be the most elegant solution, but they're that small you'll forget about ever having plugged one of them in ;)
In general, FreeBSD on the RPi seems to not be quite ready for prime time yet; too much is only "barely" or "basically" working, and there isn't critical mass for a community that has tried everything and keeps things going yet. In contrast, Raspbian seems to be heavily used and supported.
Some months ago friends gifted me with the Rpi3 I was whishing for for birthday :). The full-featured package I received included a SD pre-burnt with NOOBS. I tried Raspbian but It was slow enough to force me to moderately overclock CPU before ever thinking of opening a browser or a Word processor (and I'd bet Arch ARM, Pidora, and Ubutu Mate for Rpi would prove even heavier).

Since at the moment only FreeBSD 12.0 CURRENT supports arm64, I haven't tried it, but looking at forum's threads I think Rpi3 support is already way better than simply 'bare'. I'd be glad to hear an opinion about that from any experienced user in this forum

I discovered NetBSD thanks to Raspberry. They say NetBSD boots even on a toaster, well I have to say it suites something limited like Rasperry amazingly well. So,
NetBSD/evbarm might just happen to be what you're looking for. Anything outside Wifi works out of the box. It booted correctly the first time, gets along very well with a 12years-aged VGA monitor, it's clean fast and stable without demanding a great amount of resources.


Maybe you have never tried the right Linux distro:) Hint: Alpine Linux
SARPi is another pretty good choice.
 
Back
Top