With the arrival of OpenSSL 1.1.1, an upgraded Unbound, and some changes to the setup and init scripts, FreeBSD 12, currently in beta, now supports DNS over TLS out of the box. We show how to set it up and discuss its advantages and disadvantages.
DNS over TLS is just what it sounds like: DNS over TCP, but wrapped in a TLS session. It encrypts your requests and the server’s replies, and optionally allows you to verify the identity of the server. The advantages are protection against eavesdropping and manipulation of your DNS traffic; the drawbacks are a slight performance degradation and potential firewall traversal issues, as it runs over a non-standard port (TCP port 853) which may be blocked on some networks. Let’s take a look at how to set it up.
For a few years now, I’ve been working on and off on a set of libraries which collect cryptography- and security-related code I’ve written for other projects as well as functionality which is not already available under a permissive license, or where existing implementations do not meet my expectations of cleanliness, readability, portability and embeddability.
(Aside: the reasons why this has taken years, when I initially expected to publish the first release in the spring or summer of 2014, are too complex to explain here; I may write about them at a later date. Keywords are health, family and world events.)
Two of the major features of that collection are the OATH Authentication Methods (which includes the algorithm used by Google Authenticator and a number of commercial one-time code fobs) and the Common Platform Enumeration, part of the Security Content Automation Protocol. I implemented the former years ago for my employer, and it has languished in the OpenPAM repository since 2012. The latter, however, has proven particularly elusive and frustrating, to the point where it has existed for two years as merely a header file and a set of mostly empty functions, just to sketch out the API. I decided to have another go at it yesterday, and actually made quite a bit of progress, only to hit the wall again. And this morning, I realized why. Continue reading “Not up to our usual standards” »
Naturally, people have started asking whether FreeBSD is affected. The FreeBSD Security Officer has not yet released an official statement, but in the meantime, here is a brief look at the issue as far as FreeBSD is concerned.
One fine morning, the King summoned Gerrard, Captain of the Guard, to attend to him at Council.
Gerrard bowed as he approached his monarch. “You asked for me, Sire?”
“Gerrard, my good man, I keep hearing stories about a band of smugglers led by a man who calls himself the Fox. I want to know what your men are doing about it.”
“Sire—we have guard posts and roving patrols, and sometimes we catch a smuggler or two, but they move quietly through the woods and brush, wearing camouflage, and they can choose any direction of approach, whereas we have to stretch our forces along the entire border.”
“Very well, Gerrard. I hereby ban the manufacture, sale and use of camouflage clothing except for the needs of the Royal Guard. You are dismissed.”
Three months later, the King summoned Gerrard again.
“I hear that the smugglers are still operating, despite the measures I ordered. What do you have to say for yourself?”
“Banning camouflage clothing cut off the smugglers’ supply, but did not prevent them from using what they already had. We made more arrests when they ran out, but then they started making their own out of green, gray and black fabric, and we’re back to square one.”
“Very well. Henceforth, the manufacture and sale of green, gray or black fabric or clothing shall be illegal, except for the needs of the Royal Guard. Get to it, Gerrard.”
Some months later, Gerrard was once again summoned to discuss the matter of the Fox.
“I am very displeased, Gerrard. I would have thought your men would have little trouble catching smugglers now that they can no longer buy or make camouflage clothing. And I have been told that the villagers are restless and discontent.”
“Sire, the smugglers are tying grass, moss and branches to their clothes, and blending in better than ever before! And the villagers are complaining that the ban on camouflage and dark clothing is making it difficult for them to hunt—we forbade them to use vegetation like the smugglers do.”
“There is only one solution, then. Burn down the forests and the brush. Let us see the Fox try to sneak through a charred wasteland!”
“Do not question my orders, Gerrard. Burn it all down.”
FreeBSD just published a security advisory for, amongst other issues, a piece of code in OpenSSH’s PAM integration which could allow an attacker to use one user’s credentials to impersonate another (CVE 2015-6563, original patch). I would like to clarify two things, one that is already mentioned in the advisory and one that isn’t.
The first is that in order to exploit this, the attacker must not only have valid credentials but also first compromise the unprivileged pre-authentication child process through a bug in OpenSSH itself or in a PAM service module.
The second is that this behavior, which is universally referred to in advisories and the trade press as a bug or flaw, is intentional and required by the PAM spec (such as it is). There are multiple legitimate use cases for this, such as:
Letting PAM, rather than the application, prompt for a user name; the spec allows passing NULL instead of a user name to pam_start(3), in which case it is the service module’s responsibility (in pam_sm_authenticate(3)) to prompt for a user name using pam_get_user(3). Note that OpenSSH does not support this.
Mapping multiple users with different identities and credentials in the authentication backend to a single “template” user when the application they need to access does not need to distinguish between them, or when this determination is made through other means (e.g. environment variable, which service modules are allowed to set).
Mapping Windows user names (which can contain spaces and non-ASCII characters that would trip up most Unix applications) to Unix user names.
That being said, I do not object to the patch, only to its characterization. Regarding the first issue, it is absolutely correct to consider the unprivileged child as possibly hostile; this is, after all, the entire point of privilege separation. Regarding the second issue, there are other (and probably better) ways to achieve the same result—performing the translation in the identity service, i.e. nsswitch, comes to mind—and the percentage of users affected by the change lies somewhere between zero and negligible.
One could argue that instead of silently ignoring the user name set by PAM, OpenSSH should compare it to the original user name and either emit a warning or drop the connection if it does not match, but that is a design choice which is entirely up to the OpenSSH developers.
Update 2015-08-27 NIST rates exploitability as “medium” rather than “low” because an attacker who is able to impersonate the UID used by the unprivileged child can use a debugger or other similar method to modify the username that the child passes back to the parent. In other words, an attacker can leverage elevated privileges into other elevated privileges. I disagree with the rating, but have never had any luck getting NIST to correct even blatantly false information in the past.