Slashdot Mirror

The parent comment might be a troll but CVS still has its fans. OpenBSD development uses it and they are working on their own reimplementation, OpenCVS.

I thought you were linking to some sort of security-related bugs. But these are just plain bugs.

You're making an interesting distinction. When the folks at OpenBSD, (renowned for proactive security), audit their code, they intentionally avoid this distinction:

During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable.

Did I just call the entire computer security industry a scam? Why yes, I did. Tell me I'm wrong please, and try and add a believable argument.

Maybe you're right, but I still can't figure out how these guys are scamming us. They sure look innocent.

http://openbsd.org/
http://www.openiked.org/
http://www.libressl.org/

"LibreGlibc" already exists, and has existed for ages!

You can find the source code here:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libm/

There are numerous other superb libraries, too:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/

"LibreGlibc" already exists, and has existed for ages!

You can find the source code here:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libm/

There are numerous other superb libraries, too:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/

"LibreGlibc" already exists, and has existed for ages!

You can find the source code here:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libm/

There are numerous other superb libraries, too:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/

Sorry, forgot:

http://cvsweb.openbsd.org/cgi-...

There's the commit that confirms the "Theo himself" bit.

Then I hope you don't install it as a test environment without going through their installer, because you might find that Theo himself now sees no problem to have an enabled-per-default ntpd that - per default - talks to Google.

Let me repeat: OpenBSD talks to Google per default now. Don't believe it?

There is Google: http://cvsweb.openbsd.org/cgi-...
There is ntpd enabled by default: http://cvsweb.openbsd.org/cgi-...

I can hear you, yeah yeah, it's just a plausibility check in time syncing and it's just a HTTP HEAD or whatever. Still, it's a problem. So don't assume OpenBSD is always doing the right thing now. Double-check everything!

Then I hope you don't install it as a test environment without going through their installer, because you might find that Theo himself now sees no problem to have an enabled-per-default ntpd that - per default - talks to Google.

Let me repeat: OpenBSD talks to Google per default now. Don't believe it?

There is Google: http://cvsweb.openbsd.org/cgi-...
There is ntpd enabled by default: http://cvsweb.openbsd.org/cgi-...

I can hear you, yeah yeah, it's just a plausibility check in time syncing and it's just a HTTP HEAD or whatever. Still, it's a problem. So don't assume OpenBSD is always doing the right thing now. Double-check everything!

Firewalls have always needed licenses. (audio)

Firewalls have always needed licenses. (audio)

FTA:
$ sudo a2dismod status

Why?

Apparently some distros turn stuff on by default.

That's why I'm a huge fan of the "secure by default" philosophy.

IANAL

I'm not sure if the licenses of openssh/dropbear ssh/libssh/libssh/... allow this, if they do,
I think it's time for someone to hardcode some ssh configuration and publish it with some fucking restrictive license so that no one can tamper with the code legally, so he can buttfuck the fucking companies that do this shit..

You're not sure if they allow what? Hardcoded user passwords? Why wouldn't they? The password is outside of the responsibility of the OpenSSH server, I would hope that the OpenSSH license doesn't dictate system management practices - if a company wants to do something stupid, OpenSSH shouldn't prevent them from doing so. I don't know about the other opensource implementations, but putting any sort of restrictive license on OpenSSH would be a major shift in its licensing and would just shift manufacturers to different products.

But assuming that it is restricted by license, who is going to pay for all of this corporate buttfucking? License disputes are extremely expensive to litigate, and can an opensource project even recover "damages" for a product that they give away for free? Seems like the best they can hope for is to spend millions of dollars to get the company to stop what it's doing.

I beleive the community will prefer firewalls/routers that have such packages installed

I don't know what "community" you're talking about, but most of the community that is purchasing these off-the-shelf point and click security products couldn't tell you the difference between a management over SSH versus one over Telnet, so they certainly aren't going to be scouring the documentation to see which SSH implementation it uses. The users that care are already using something like pfSense.

I ask this in good faith -- why is there open source ransomware?

The short answer is that some people have bad values. If you want to dive deeper you could consider the OpenBSD licensing philosophy as a proxy for the Open Source or Free Software movement. The software and its code become an end in itself, What is "good" is defined in terms of working code that complies with the license. The ultimate purpose of the code is practically irrelevant. From time to time there are controversies that arise in regard to some proposed change in the license of some software. I seem to recall several for the GPL. These generally seem to be aimed at harming US national defense, or some sector of the economy. You can probably chalk aspects of this to the nihilism of orur present age.

Oh, something for you to consider: http://www.openbsd.org/errata5...

OpenBSD is much smaller and simpler than any mainstream OS, and has had a laser focus on security for years. Security is their number one goal, above usability, features or anything else... and yet they need more-than-monthly updates to fix security defects. That should give you an indication of just how hard a problem this is.

Their own page reports that they've fixed a whole host of bugs. They'd not have fixed those bugs if they were bug free.

Here's a recent example:
http://www.openbsd.org/errata5...

I'm not sure why one would lie about such.

I think OpenSSL might be a special case here. By an odd coincidence I was watching the OpenBSD devs talks on LibreSSL yesterday and they actually covered backporting fixes from OpenSSL.

http://www.openbsd.org/papers/eurobsdcon2014-libressl.html - See the section title "apply the brakes". (for those interested, the slides here are from this video: https://www.youtube.com/watch?v=WFMYeMNCcSY)

My overall impression is that the OpenSSL developers don't really make peoples lives easy when it comes to backporting security fixes because they'll be bundled with a heap of other, poorly tested crap at the same time. This isn't helped by the quality of their code.

OTOH, OpenBSD's kernel is about 10X the size of Xen (where the BSD mantra of 'correctness' has a much tighter focus). As isolation mechanisms go, I trust Xen before any monolithic kernel. The upshot is that Xen also gives me the rich features (incl. drivers) of Linux and Windows.

Awwwww, you are so cute. You trust Xen more than kernel xyz? Really?

First of all, please read this.
Then take a look at this.

There are, let's see... right now, 35 CVEs assigned to the Xen project, in 2015 alone? 40 CVEs in 2014?

Compare and contrast with the number of CVEs published for OpenBSD. And the number of patches available for the latest version (5.8) of OpenBSD.. Here is a hint: 99% of these patches do not imply your machine is going to be ''owned'' by someone exploiting the bugs found. Yes, even the OpenSMTPD patches are pretty mild.

You can keep your Qubes OS, thank you very much, I'll stick to OpenBSD, despite all its defaults and warts.

Words of wisdom to meditate:

You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

(Source.)

Say what you will of this guy, he has got a point. Virtualization is great, but not for security. Period.

Linus Torvalds: ...Security of any system can never be perfect. So it always must be weighed against other priorities — such as speed, flexibility and ease of use — in a series of inherently nuanced trade-offs....

Fortunately, there are open source operating systems available where security is less of a trade-off and more of a priority, such as OpenBSD, where the developers maintain a laser focus on security.

I don't want any of that useless crap that the poster considers "innovation"

Here's some real innovation:
http://www.openbsd.org/cgi-bin...

When will OpenBSD's developers finally design an easier upgrade process from one version to another? How can anyone use this OS if every time there's a new version you either format your hard drive or go through this lengthy and cumbersome upgrade process? http://www.openbsd.org/faq/upg...

Is that so impossible to have a debian-syle "apt-get dist-upgrade"?!

continually improve the _existing_ software.

I'll just leave this slide of a presentation by Theo here
"Disruptive innovation is encouraged"

I use OpenBSD because it's simple, and they continually improve the _existing_ software.

Existing software like LibreSSL? (OpenBSD rewrite of OpenSSL)
Or OpenSMTPD? (OpenBSD rewrite of an MTA)
Or maybe something simpler, like doas(1)? (OpenBSD rewrite of sudo)

Lots of newly-written software in OpenBSD. These are only three examples i could readily think of, and they're all fairly recent.

I guess your notion that NetBSD is bleeding edge is based on similar bizarre views.

Well, part of that rewriting may be due to their (OpenBSD's) rejection of the GPL. Well, not the examples above, but maybe some other software.

I use OpenBSD because it's simple, and they continually improve the _existing_ software.

Existing software like LibreSSL? (OpenBSD rewrite of OpenSSL)
Or OpenSMTPD? (OpenBSD rewrite of an MTA)
Or maybe something simpler, like doas(1)? (OpenBSD rewrite of sudo)

Lots of newly-written software in OpenBSD. These are only three examples i could readily think of, and they're all fairly recent.

I guess your notion that NetBSD is bleeding edge is based on similar bizarre views.

It's unclear whether most of the FUD in this discussion is directed at the GPL itself or specifically v3. But it's entirely unfounded.

It's not FUD, and its about the GPL in general - although being GPL3 makes it worse. "GPL2 or later" would have been a better (but still flawed) choice.

You know why libraries aren't generally licensed GPL, right? Anything that links to them has to have the exact same license as the library. For instance, the GPL2 licensed Inkscape can't use this library.

That's the difference between the GPL and the LGPL. You can link to LGPL libraries from any software; you can only link to GPL licensed libraries from code with the same version of the GPL.

In RMS' ideal world, all software would move to the latest GPL and it wouldn't be a problem. Good luck convincing these guys of that.

This is the appropriate license for this image format.

The GPL is not the appropriate license for any general-purpose library. That's what the LGPL is for. Or, like most reference implementations, a non-copyleft license like the MIT license.

Look, I get it, you're a promoter of software freedom. So am I. But this is the real world, and this is a reference implementation. There are conventions to follow for reference implementations, and an OSS non-copyleft license is one of those conventions. This image format could outperform every other format on the planet and it will still see no adoption outside of academia unless there's a compatibly licensed library available. Unless it gets relicensed, or someone writes a non-GPL library, this will go down as just another interesting format that sees no adoption whatsoever.

Only an idiot exposes a Linux box directly to the Internet.

OpenBSD 3.6 (Nov 2004) changelog:

New functionality:
- A new NTP daemon written from scratch, which ought to fit the needs of most NTP users.

Man page for 3.6

Ergo, OpenNTPD has been a server since its birth. New information indeed.

In short, you're comparing a simple client that just looks at the time on the wall vs something that's trying to be accurate and can act as the server side of the equation.

OpenNTPD does run as a server. Or have I been syncing my clocks all these years to something non-existent?

listen on address [rtable table-id]
        Specify a local IP address or a hostname the ntpd(8) daemon should listen on.

Jesus Christ! Do we have to explain the basics to you?!

Security by obscurity is bunk. You should know this.

You have heard about the Cathedral and the Bazaar, right?

Some of the most secure things are out in the open, for everyone to see.

OpenBSD and LibreSSL and OpenSSH are some of the most secure, bug-free software ever developed, and their code is out in the open. They're so secure because they're developed openly!

http://www.openbsd.org/cgi-bin...

-X
        Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
        X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
        For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.
-x
        Disables X11 forwarding.
-Y
        Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.

http://www.openbsd.org/cgi-bin...

ForwardX11Trusted
        If this option is set to “yes”, remote X11 clients will have full access to the original X11 display.
        If this option is set to “no”, remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time.

In summery it seems that -X is more secure than -Y but can break things in some cases.

http://www.openbsd.org/cgi-bin...

-X
        Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file.
        X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.
        For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.
-x
        Disables X11 forwarding.
-Y
        Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.

http://www.openbsd.org/cgi-bin...

ForwardX11Trusted
        If this option is set to “yes”, remote X11 clients will have full access to the original X11 display.
        If this option is set to “no”, remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time.

In summery it seems that -X is more secure than -Y but can break things in some cases.

Well, I suppose it can finally no longer be said that the Sparcstation 10 I keep here just for old times' sake can still run "current Linux distributions."

NetBSD and OpenBSD both run on the SparcStation 10 and they're actual UNIX operating system. http://wiki.netbsd.org/ports/s... http://www.openbsd.org/sparc.h...

Now you''ll have to switch to OpenBSD (like everyone else who wants a working unix system /flame).

According to the article, it's a bug in PAM.

Then the article (which I wouldn't bother to read) is misleading.

The bug is inside openssh proper. This is how they fixed it:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/auth2-chall.c.diff?r1=1.42&r2=1.43&f=h

Basically, OpenSSH was accepting a list of 'keyboard interactive devices' where the same device apeared thousands of times, completely bypassing the MaxAuthTries setting from sshd_config (default 6).

This is well explained in kingcope's original report.

https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/

It's very much a bug, and the code in auth2-call.c looks silly enough (just like the fix, btw) that there's a high probability of other such gross bugs in there.

And as OpenBSD developer Marc Espie says in his message,

Not surprisingly, as the patch clearly shows, the problem is right smack in the middle of USE_PAM code.

That doesn't seem to be the case.

In fact, my will guess is that the default pam_faildelay is what stays in the way of this bug's being exploitable on Linux.

Well what you basically wish for is corporate-like network with authentication to local systems and to network usage. It can't be done without enterprise class systems - you will need an internet access proxy/gateway for accounting and enforicing access policies for network, user directory to enforce password usage and restrict access to certain machines for certain users (namely your son), network access protection system (and network hardware supporting it) so your son can't just use his Linux machine to access network however he likes.

Um, what?

He's not setting up a corporate network, and he's not protecting vital data. Hardcore security isn't required (and can still be had, at some inconvenience to the users, using things like this, for instance), If he's got a UNIX-based firewall that can run cron scripts, that's all he needs.

Try this:
1) Put grandparents' machines on static IPs (or set their IPs on the DHCP server, if whatever's serving DHCP supports it).
2) Have grandparents put a password on their Windows boxes and set the screensaver to lock after a few minutes.
3) Set up a cron script to turn off internet access for all IPs except the grandparents' machines at a certain time, then turn it back on in the morning.
4) Disable the cron script and disable internet access altogether if the kids are grounded.
5) Use the firewall logs to see what the kids are doing. A little scripting can generate reports for you, if you want.

If only one kid is grounded, it's a bit trickier, but still doable. A kid could unplug the cable or turn off one of the grandparents' machines and take the IP, but that would be best dealt with as a social issue (i.e. beat the kid's ass if he does).

I use a similar setup here and it works like a charm. I use OpenBSD for the firewall, but Linux and pfSense have the same capability.

We need to ask ourselves, would this incident have even happened if they had been using OpenBSD? It's hard to say for sure, since details about this incident are scant. But we do know that OpenBSD is designed from the ground-up to be as secure as possible, and its developers put an immense focus on security. It has proven itself to be among the most secure, yet still practical, operating systems, if not the most secure for general-purpose computing. So when one has to put together a server or even an entire network, and security is a real concern, then I think that OpenBSD is the only viable option available.

Are you running OpenBSD on all of your computers, including your wife's? If you aren't, then you have a glaring security hole in your network infrastructure. For all intents and purposes, OpenBSD is as secure as you're going to get in a networked environment. It isn't perfect, but it's the best there is. It doesn't matter how obscure your wife's email address is, or how long her password is, or how many special characters it contains, if you're running a non-OpenBSD operating system that may be compromised by a keylogger or other malicious software. OpenBSD has proven itself to be very resilient to security flaws and attacks. So it's the only sensible operating system to run on all of your devices. If a device is not capable of running OpenBSD, then you're better off not using that device at all.

Step One
Step Two

That's patching it the smart way.

If you really care about stuff like "a free and unrestricted internet", and want to ensure the safety and future of "free human communication", then just donate to OpenBSD. You'll be supporting a group of people who take security very seriously (their software is among the most secure there is), who know all about freedom (their preferred software license is about as free as you can get), and who provide some of the most critical Internet communication software there is (OpenSSH, LibreSSL, and OpenSMTPD). Making a donation to OpenBSD is a great way to meet the criteria that you set forth.

If you really care about stuff like "a free and unrestricted internet", and want to ensure the safety and future of "free human communication", then just donate to OpenBSD. You'll be supporting a group of people who take security very seriously (their software is among the most secure there is), who know all about freedom (their preferred software license is about as free as you can get), and who provide some of the most critical Internet communication software there is (OpenSSH, LibreSSL, and OpenSMTPD). Making a donation to OpenBSD is a great way to meet the criteria that you set forth.

What is this, 1980? There's no Internet that everybody's using?

Look, it's not 1980. It's 2015. You don't have to "keep it local" in order to see how your money is being used.

Donate to OpenBSD, and you'll be able to follow along as their already-superb software continues to get even better and better. Not only would you be supporting the development of a free and extraordinarily secure operating system, but the people responsible for OpenBSD are also responsible for tremendously important software like OpenSSH and LibreSSL. This is some of the most important open source software around. Since it's open source, we can all inspect its code to see what they're doing with our donations.

The OpenBSD developers don't fuck around. These are serious people, creating seriously secure, reliable and useful open source software products. Your donation to them doesn't just help a few people in your vicinity. Your contributions to OpenBSD helps out almost the entire world. The software they work on is just that damn important!

So do the only sensible thing there is to do: donate to OpenBSD.

What is this, 1980? There's no Internet that everybody's using?

Look, it's not 1980. It's 2015. You don't have to "keep it local" in order to see how your money is being used.

Donate to OpenBSD, and you'll be able to follow along as their already-superb software continues to get even better and better. Not only would you be supporting the development of a free and extraordinarily secure operating system, but the people responsible for OpenBSD are also responsible for tremendously important software like OpenSSH and LibreSSL. This is some of the most important open source software around. Since it's open source, we can all inspect its code to see what they're doing with our donations.

The OpenBSD developers don't fuck around. These are serious people, creating seriously secure, reliable and useful open source software products. Your donation to them doesn't just help a few people in your vicinity. Your contributions to OpenBSD helps out almost the entire world. The software they work on is just that damn important!

So do the only sensible thing there is to do: donate to OpenBSD.

Just donate to OpenBSD. They produce some of the best software there is, and ever has been.

For crying out loud, the first step in creating any kind of a secure software environment is to use OpenBSD.

OpenBSD takes security more seriously than pretty much every other OS out there. Security isn't an afterthought with OpenBSD; security is the primary focus of its developers. Its code is thoroughly reviewed, with the OpenBSD developers even forking and fixing external libraries when external code doesn't pass muster.

If you claim to take security seriously, then I think your only choice is to be using OpenBSD.

From http://www.openbsd.org/errata5... (emphasis mine)

009: SECURITY FIX: June 11, 2015 All architectures
Fix several defects from OpenSSL:

        CVE-2015-1788 - Malformed ECParameters causes infinite loop
        CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time
        CVE-2015-1792 - CMS verify infinite loop with unknown hash function

Note that CMS was already disabled in LibreSSL. Several other issues did not apply or were already fixed and one is under review.
For more information, see the OpenSSL advisory.
A source code patch exists which remedies this problem.

A fix is already available.

BSD is dying for how long again? It's still around and having monthly releases. For open source projects, popularity contests are much less important. With massive existing user base, Hadoop will be actively maintained for long time. So if you already familiar with it and it serves the needs of your project, go right ahead.

The only difference that results in (resulted in, it's getting better lately) is that BSD-licensed code gets used, while GPL'ed code doesn't get used, for commercial purposes. Furthermore, getting upstream to add your changes is cheaper since you no longer need to maintain them yourself, so companies still have good reasons to contribute back.
The OpenBSD people's take on the matter is:

People sometimes ask if it bothers us that our free work is put into commercial products. The answer is, we would prefer that our good code be widely used rather than have commercial software vendors reimplement and create badly coded or incompatible alternative solutions to already solved problems. For example, it is likely that SSH is a widely used protocol due to this freedom, much more widely used than if restrictions had been placed on how people used the OpenSSH code. If a free SSH solution was not available for vendors to use (in their multitude of rapidly developed products), they would have written or purchased some crummy off-the shelf version instead.

Now, about

If you publish the same code under GPL, and even a single other developer shows some interest and adds something to your work, and in turn decides to distribute that to others, you may get rewarded by additional functionality.

FTFY. It's kind of important to note that as long as you don't plan on distributing your modified version (and in many cases, why would you?) , you're not required to, well, distribute your modified sources.
Then, many modifications will just be horrible hacks to scratch some immediate itch, which you wouldn't at all want in your source base, so GPLing stuff is far from providing a guaranteed enhancement return, even if there is interest.

Since the OpenBSD 5.5 release a year ago, the OS is fully ready for the onslaught of 2038.