Three important security advisories issued today.

fonz said:
kpa said:
The third one is the most serious and affects all supported versions of FreeBSD, update ASAP.

http://www.freebsd.org/security/advisories/FreeBSD-SA-14:08.tcp.asc
Click to expand...
Just to make sure I read it correctly: if you're using
Code: 
scrub in all
in /etc/pf.conf you're already okay (at least for the time being), right?
Click to expand...

I'm not sure about that, on the pfSense forums I spotted this:

https://forum.pfsense.org/index.php?topic=76216.msg415443#msg415443

If that is true and the TCP reassembly hasn't been implemented in PF on newer (> 8.3) versions of FreeBSD then scrub in all won't really help.
 
kpa said:
I'm not sure about that, on the pfSense forums I spotted this:

https://forum.pfsense.org/index.php?topic=76216.msg415443#msg415443

If that is true and the TCP reassembly hasn't been implemented in PF on newer (> 8.3) versions of FreeBSD then scrub in all won't really help.
Click to expand...
Hmm, that's worth looking into. The way I read it, the SA really seems to suggest scrub in all as a viable workaround :q

I'll be updating my systems tomorrow morning anyway, but still :\
 
Thanks for the "heads up" on the advisories. FreeBSD is good about that. But... I've pretty much ditched the idea of OpenSSL. It's just too much worry for my blood any more.

That's why I'm posting this message with a Webkit based browser running PolarSSL.
 
Is there an alternative OpenVPN build?

Talking of which:

Code: 
May  1 07:21:00 freebsd10 openvpn[1101]: PID_ERR replay-window backtrack occurred [1] [SSL-4] [0_01111111111111111111111111111111111111111111111111118888888888] 0:100 0:99 t=1398925260[0] r=[-1,64,15,1,1] sl=[28,64,64,272]
May  1 07:35:21 freebsd10 openvpn[1101]: PID_ERR replay-window backtrack occurred [2] [SSL-4] [00_0000000000000000000000000000000000000000000000000000000000000] 0:16948 0:16946 t=1398926121[0] r=[-3,64,15,2,1] sl=[12,64,64,272]

??
 
liblit said:
Is there an alternative OpenVPN build?

Talking of which:

Code: 
May  1 07:21:00 freebsd10 openvpn[1101]: PID_ERR replay-window backtrack occurred [1] [SSL-4] [0_01111111111111111111111111111111111111111111111111118888888888] 0:100 0:99 t=1398925260[0] r=[-1,64,15,1,1] sl=[28,64,64,272]
May  1 07:35:21 freebsd10 openvpn[1101]: PID_ERR replay-window backtrack occurred [2] [SSL-4] [00_0000000000000000000000000000000000000000000000000000000000000] 0:16948 0:16946 t=1398926121[0] r=[-3,64,15,2,1] sl=[12,64,64,272]

??
Click to expand...

Your question doesn't seem to be related to the security advisories. Wrong thread?
 
@liblit:

You're probably referencing my post. No, there is no prebuilt OpenVPN/PolarSSL available as a FreeBSD package. You'd have to build that yourself. Get the Dutch source distribution and recompile. As far as my own browsing, I'm not using any VPN. The default reference implementation for Webkit used to have curl as its network backend. So, for my purposes, it was easy to recompile curl with PolarSSL, which simultaneously converted my (close to) reference implemenation of webkit to use PolarSSL.

You have to watch the security advisories on polarSSL and curl however :-)
 
Last edited by a moderator:
@liblit:

I'm not saying PolarSSL is any better. Could it be worse? Use at your own risk. Same with curl. It's a risky business at any rate, with no very good short term solutions. I do question why OpenBSD is fooling around with a redo of OpenSSL. It seems there are references on the net saying that the PolarSSL codebase is clearer, and more manageable. That's a thing that is often a matter of wildly varying opinions. I haven't really looked at the code myself. There can be a bug in even the simplest code.

Edit:

Hand me a Heineken whilst I slap my head silly. It's the license, of course, that is the reason OpenBSD isn't using it (unless Theo of BSD knows something I don't know). That's seriously plausible. For PolarSSL the license options are proprietary and GPL2. Why couldn't it be MIT or BSD? Oh well... back to the Heineken.

Edit2:

I don't really drink any more. It doesn't help the coding at all. PolarSSL is a relatively unknown quantity to most people, including myself. In spite of that, these days people are willing to consider (almost any) alternative. It would be nice if some of the really sharp crypto experts around the world would analyze the PolarSSL codebase, and give it some kind of stamp (of approval or otherwise). Wouldn't it be nice? And that's another beer commercial. On the other hand, who in their right mind would take on that level of responsibility? Maybe that's more the crux of the problem. I know they're vetting the OpenSSL code now (LibreSSL) - but I understand it's tough slogging.

The GPL2 licensing isn't very great for a BSD distribution, but most end users wouldn't care about it. Anyway, the question from @liblit may in fact be related to a fixed OpenVPN/OpenSSL package. I don't know the answer to that question.
 
Last edited by a moderator:
PolarSSL is an OpenVPN compile option in the ports tree, however with the caveat:
Code: 
checking polarssl pkcs11 support... configure: error: polarssl has no pkcs11 wrapper compiled in
Smartcards, etc.

The errors are in the wrong thread now that you mention it, I wasn't going to follow them up initially, but I might take the opportunity!
 
liblit said:
PolarSSL is an OpenVPN compile option in the ports tree, however with the caveat:
Code: 
checking polarssl pkcs11 support... configure: error: polarssl has no pkcs11 wrapper compiled in
Smartcards, etc.

The errors are in the wrong thread now that you mention it, I wasn't going to follow them up initially, but I might take the opportunity!
Click to expand...

Any kind of SSL is a crap shoot IMO. I can't vouch for PolarSSL in any way. I've been using it, but what does that mean? So, I can't really say much one way or the other, positive or negative. Unfortunately, that's the case with any library we use, for SSL or for anything else. If there's an issue, we don't know until after the fact, unless we're that really sharp developer who specializes in the program, and has vetted it. I certainly haven't vetted the PolarSSL library. So, good luck with whichever way you go! Should you wait for LibreSSL? Who knows? Some days, I think it's better to go with just plain text so I don't have to deal with bogus certificates and cipher powerdowns. No false sense of security that way. Kidding, I think :OO
 
kpa said:
fonz said:
kpa said:
The third one is the most serious and affects all supported versions of FreeBSD, update ASAP.

http://www.freebsd.org/security/advisories/FreeBSD-SA-14:08.tcp.asc
Click to expand...
Just to make sure I read it correctly: if you're using
Code: 
scrub in all
in /etc/pf.conf you're already okay (at least for the time being), right?
Click to expand...

I'm not sure about that, on the pfSense forums I spotted this:

https://forum.pfsense.org/index.php?topic=76216.msg415443#msg415443

If that is true and the TCP reassembly hasn't been implemented in PF on newer (> 8.3) versions of FreeBSD then scrub in all won't really help.
Click to expand...

I've been reading the PF source code a bit. My conclusion is that if we assume that the PF source code uses the correct terms for fragments and segments, fragments for packets that are too large to fit into the MTU and segments for units for the reassembly on packets that have arrived out of order, PF does not do segment reassembly at all. This means that scrub rules did not protect against the bug that was fixed in FreeBSD-SA-14:08.tcp.
 
@xtaz: thanks for the link. I found myself in agreement with much of what's on that page. Complexity is the enemy of security, that's for sure. It's not just the secure code, and as the author states - the compiler itself works into the equation. LLVM/Clang is wonderful, but simple it's not. It makes me wonder if I should be a complete luddite and use a reworked and vetted version of the small/simple "Plan 9" compiler. LOL. Oh well.

@kpa: Thanks for the information. Apparently, the venerable TCP/IP stack of BSD is still capable of surprising us. So much of the world's TCP/IP code goes back to BSD. Even Windows, to some extent. So - my question is - how far back does this go and might it affect other operating systems built on facsimiles of the BSD TCP/IP stack? Yegads.
 
Last edited by a moderator:
Just for reference, there is a C compiler out there for which a proof of correctness was done. I'm not sure how complete it is, it would not allow some things which C allowed last time I checked. Even if the performance of the generated binaries may be slower than what others can do - I would encourage to build anything that needs to be correct at all costs (kernel, crypto, ...) with such a tool.
 
Crivens said:
Just for reference, there is a C compiler out there for which a proof of correctness was done. I'm not sure how complete it is, it would not allow some things which C allowed last time I checked. Even if the performance of the generated binaries may be slower than what others can do - I would encourage to build anything that needs to be correct at all costs (kernel, crypto, ...) with such a tool.
Click to expand...

I imagine you're referring to CompCert. Yes, it's still a subset. But, there's an interesting project that segues the objective in general terms, but is targeted at LLVM:

http://www.cis.upenn.edu/~stevez/vellvm/

"Segue" is not really the correct term, as it's not a derivative... it just uses some ideas/tools in the same domain. Seems that it's not a silver bullet, but maybe it's a small stake.
 
I've upgraded my system to 10-p2 and then 10-p3 but my jails still have unrestricted access to /dev. Why did the devfs patch have no effect?

PS For the moment I've fixed it manually as stated in the security advice.
 
You must log in or register to reply here.
Back
Top