| View previous topic :: View next topic |
| Author |
Message |
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
 Posted: Wed Jun 28, 2017 12:09 pm Post subject: |
 |
|
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9445
| Quote: | | In systemd through 233, certain sizes passed to dns_packet_new in systemd-resolved can cause it to allocate a buffer that's too small. A malicious DNS server can exploit this via a response with a specially crafted TCP payload to trick systemd-resolved into allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it. |
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54577
Location: 56N 3W
|
| Posted: Wed Jun 28, 2017 1:11 pm Post subject: |
|
|
Continued from The Politics of systemd Part 2
The thread has been quiet for a few weeks so looks like a good place for a split
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Wed Jun 28, 2017 2:18 pm Post subject: |
|
|
| NeddySeagoon wrote: | | The thread has been quiet for a few weeks so looks like a good place for a split |
yep, but starting new one with a CVE is evil  |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10655
Location: Somewhere over Atlanta, Georgia
|
| Posted: Wed Jun 28, 2017 2:33 pm Post subject: |
|
|
What? That's crazy talk. All other software is well known to be bug free!
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Wed Jun 28, 2017 6:04 pm Post subject: |
|
|
I will leave this right here...
| Quote: | The process turns a request for binary DNS data into into XML, feeds it
into the sytemd/dus ecosystem, which turns it into binary DNS to send
it to the forwarder. The binary DNS answer then gets turned into XML
goes through systemd/dbus, then is turned back into binary DNS to feed
back into glibc. Apart from errors in this process, like last year's
CVE on cache poisoning attacks, this means the systemd people need to
very actively maintain their code whenever a new feature or RRTYPE is
added to the DNS protocol. Maintenance and bugfixes is not systemd's
strong point. This architecture is overly complex and unneccessary. |
https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html |
|
| Back to top |
|
|
rob_dot_p
n00b
Joined: 28 Jan 2017
Posts: 30
|
| Posted: Wed Jun 28, 2017 7:54 pm Post subject: |
|
|
Just copy+paste the entire mail here, it's worth reading. Sounds like a total disaster.
________________________________________________________________
systemd-resolved requires a forwarder. It is not a full DNS recursive
server. So source port randomization is pretty useless as you are most
likely just doing DNS on the local network.
Also, "improve resilience against cache poisoning" is quite the weasel
wording. Especially since it trusts faster answers over slower ones over
different interfaces. The design is still horribly broken.
At devconf, the systemd people described the system to us. Things might
have changed since then and we should verify that. With that, let me
mention what I remember:
- It uses nsswitch to basically take over gethostbyname*() and
getaddrinfo(). This means any software using a DNS library like ldns,
unbound, bind, knot, etc bypasses this system and gets an inconsistent
DNS view from the rest of the system. It explictely does not support
those kind of applications. Due to its issues below, this is a problem
for applications insisting on DNSSEC answers (eg postfix). It does not
supply a "local DNS server" that those dns libraries could use to get
a consistent view.
- it fudges with /etc/resolv.conf, but it does not provide a DNS server.
So it cannot put 127.0.0.1 in resolv.conf. This means ANY application
using /etc/resolv.conf that does not use glibc is going to go around
systemd-resolvd. Yet systemd-resolvd messes with resolv.conf.
- The process turns a request for binary DNS data into into XML, feeds it
into the sytemd/dus ecosystem, which turns it into binary DNS to send
it to the forwarder. The binary DNS answer then gets turned into XML
goes through systemd/dbus, then is turned back into binary DNS to feed
back into glibc. Apart from errors in this process, like last year's
CVE on cache poisoning attacks, this means the systemd people need to
very actively maintain their code whenever a new feature or RRTYPE is
added to the DNS protocol. Maintenance and bugfixes is not systemd's
strong point. This architecture is overly complex and unneccessary.
- It won't work well with applications that have their own DNS code
itside. Such as browsers. This becomes worse when you think about
browsers supporting draft-shore-tls-dnssec-chain-extension.
- It is yet another program/daemon that runs races with other software
in controlling /etc/resolv.conf. Eg VPN software adding nameservers.
- There is no option to become a full recursive DNS server. It depends
on a forwarder being obtained via DHCP. This means any broken
forwarder leads to a broken setup. eg an upstream that strips DNSSEC.
- It accepts DNS forwarders for all its interfaces. That means if you
are on wifi and 3g, or ethernet and wifi, you have more than one
DNS server from logically different networks. With no way of
guaranteeing which logical network you asking.
- It sends out a DNS queries over all its obtained DNS servers all the
time. This means DNS queries for split-DNS view resources leak all
over the internet.
- It accepts the first valid answer. This could be an unsigned answer.
This means a local attacker (eg wifi hotspot) has an advantage over
the actual real DNS forwarders.
- It prefers an answer over an NXDOMAIN as workaround for the above.
So if some A record does not exist, the NXDOMAIN is ignored in
favour of a forged, or rogue wildcard type, answer.
- It does not implement RFC-5011 properly. It might remove trusted keys
upon seeing the revoke bit instead of waiting the time period
specified in RFC-5011.
- I believe it does not support DNS-over-TLS
- I _believe_ it does not support network changes that requre a cache
flush, for instance a VPN network with an internal *.corp.company.com
whose entries need to be removed from the cache when the network is
lost.
- I _believe_ it does not handle trust anchors linked to DNS nameserver
IP addreses. Needed for DHCP servers relaying multiple domain names
for resolving and VPN situations like draft-pauly-ipsecme-split-dns-01
- I _believe_ it will not able to reconfigure forwarders on the fly.
I was told it was not a caching dns server. But that seems to be the
case now. Which in a way makes things worse, because hotspots could then
keep long lived forged records in my cache? Unless they flush all the
cache on any network interface change, which in itself would cause me
to leave my fingerprints all over the internet for pervasive monotiring
attacks.
__________________________________________________________________________ |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3689
Location: Rasi, Finland
|
| Posted: Wed Jun 28, 2017 10:10 pm Post subject: |
|
|
| gwr wrote: | I will leave this right here...
| Quote: | The process turns a request for binary DNS data into into XML, feeds it
into the sytemd/dus ecosystem, which turns it into binary DNS to send
it to the forwarder. The binary DNS answer then gets turned into XML
goes through systemd/dbus, then is turned back into binary DNS to feed
back into glibc. Apart from errors in this process, like last year's
CVE on cache poisoning attacks, this means the systemd people need to
very actively maintain their code whenever a new feature or RRTYPE is
added to the DNS protocol. Maintenance and bugfixes is not systemd's
strong point. This architecture is overly complex and unneccessary. |
|
It's like compressing base64 -encoded compressed file.
My mind is melting...
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Thu Jun 29, 2017 12:31 am Post subject: |
|
|
| Zucca wrote: | It's like compressing base64 -encoded compressed file.
My mind is melting... |
I almost would have thought someone literally made up that little blurb as a parody. There are no words. I'm I reading that right, that there's XML parsing parsing overhead involved not once, but twice for every DNS query? Do they actually care about...OH I don't know...how "well" anything works?
EDIT: Just read the whole thing...for God's sake...guess that answers my question. Those folks are the kings of the "how difficult could it be?" mindset.
Tom |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Thu Jun 29, 2017 5:13 am Post subject: |
|
|
| The fun of it is, the systemd devs are going to complain that its too slow, so for another reason to put systemd in the kernel. All to make up for their inefficient code... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Jun 29, 2017 6:49 am Post subject: |
|
|
| ct85711 wrote: | | The fun of it is, the systemd devs are going to complain that its too slow, so for another reason to put systemd in the kernel. |
LOL.
I found this telling: | Paul Wouters wrote: | | [That] in general was my problem when I met the systemd people to talk about this. My use cases were simply ignored as not relevant. |
That sounds familiar. |
|
| Back to top |
|
|
Dominique_71
Veteran
Joined: 17 Aug 2005
Posts: 1890
Location: Switzerland (Romandie)
|
| Posted: Thu Jun 29, 2017 11:50 am Post subject: |
|
|
| rob_dot_p wrote: | Just copy+paste the entire mail here, it's worth reading. Sounds like a total disaster.
...
- It won't work well with applications that have their own DNS code
itside. Such as browsers. This becomes worse when you think about
browsers supporting draft-shore-tls-dnssec-chain-extension. |
So the next step will be to integrate an internet explorer clone into systemd 
_________________
"Confirm You are a robot." - the singularity |
|
| Back to top |
|
|
Dominique_71
Veteran
Joined: 17 Aug 2005
Posts: 1890
Location: Switzerland (Romandie)
|
| Posted: Thu Jun 29, 2017 11:53 am Post subject: |
|
|
| steveL wrote: | | ct85711 wrote: | | The fun of it is, the systemd devs are going to complain that its too slow, so for another reason to put systemd in the kernel. |
LOL.
I found this telling: | Paul Wouters wrote: | | [That] in general was my problem when I met the systemd people to talk about this. My use cases were simply ignored as not relevant. |
That sounds familiar. |
It remain me about old stories of audio desktop users being qualified as desktop haters. So the only thing these guys learned under all that time was to polite there language!
_________________
"Confirm You are a robot." - the singularity |
|
| Back to top |
|
|
proteusx
Guru
Joined: 21 Jan 2008
Posts: 340
|
| Posted: Thu Jun 29, 2017 12:17 pm Post subject: |
|
|
| Criticizing (((systemd))) is hate speech. |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Thu Jun 29, 2017 1:34 pm Post subject: |
|
|
| proteusx wrote: | | Criticizing (((systemd))) is hate speech. |
Yes, it is. I am speaking about how much I hate it. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3518
|
| Posted: Thu Jun 29, 2017 3:47 pm Post subject: |
|
|
| steveL wrote: | | ct85711 wrote: | | The fun of it is, the systemd devs are going to complain that its too slow, so for another reason to put systemd in the kernel. |
LOL.
I found this telling: | Paul Wouters wrote: | | [That] in general was my problem when I met the systemd people to talk about this. My use cases were simply ignored as not relevant. |
That sounds familiar. |
NOTABUG WONTFIX, no doubt.
Either that or their solution will be "dbus-over-IP" and quit using port 53 for DNS queries - for starters.
(Sometimes it's fun to come up with the stupidest idea possible in a given setting, to either see who salutes it or to predict the actions of (insert noun here).
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
rob_dot_p
n00b
Joined: 28 Jan 2017
Posts: 30
|
| Posted: Thu Jun 29, 2017 6:39 pm Post subject: |
|
|
The last week or so Lennart showed up at Reddit a couple of times and defended his projects.
Yesterday after someone shared the vulnerability, he went on a rant about how much systemd cares about security and how well they're actually doing in that area.
He disappeared again after somebody asked why systemd devs silently fix vulnerabilities.
If somebody is interested in what he has to say:
| Quote: | So, here's how I would "spin this turd" if I was "Pottering".
I'd probably say, yeah, software has bugs! systemd has, the Linux kernel has, and so does Apache or NGINX. It's how things are, and if you do software you should know that.
Which hence raises the question: does systemd have more bugs per sloc than other software? I don't have numbers, but I am pretty sure we are actually pretty OK on that front, probably better than most other projects, simply because there are plenty eyeballs watching what we do, we do have a pretty tightly controlled commit regime, with reviews and CI and stuff (not saying we couldn't do better, but I am pretty sure we are probably better than average on this front, when it comes to Open Source software). But anyway, I'd be quite curious to see some stats of let's say CVEs per time and per slocs, not aware of any though. (And yeah, CVEs aren't a great metric, but I figure they are still better than nothing.)
And then, I'd probably point you to the fact that systemd actually does a lot, and really a lot, to systematically reduce the impact of such bugs, to minimize what you can do should you have managed to exploit some system service. systemd these days comes with a ton of sandboxing features, and for the service this CVE is about we make use of a lot of them:
https://github.com/systemd/systemd/blob/master/units/systemd-resolved.service.m4.in
Specifically, resolved runs in a file system sandbox where the host OS tree is mounted read-only in almost its entirety. The /dev it sees is unpopulated except for /dev/urandom, /dev/zero, /dev/null, and a few others, i.e. the UNIX pseudo devices that are API, but don't actually refer to a physical device. The /home directory it sees is entirely empty. It has a private instance of /tmp and /var/tmp. It can't create any kind of socket except AF_INET/AF_INET6, AF_UNIX and AF_NETLINK (for example no AF_PACKET), it runs with a pretty strict system call filter in effect, and a couple of other things. On top of that, what this unit file doesn't show: resolved drops the few remaining privs it has after initialization, then running as the "systemd-resolve" user. And here again, all of this put together is actually substantially more than most other projects implement when it comes to sandboxing their stuff.
Now, all of this is enabled for resolved, but most of it available pretty easily to other services too, it's just a matter of turning them all on (and before you ask, why is this opt-in, and not opt-out — the answer is compatibility: as we add sandboxing features we cannot break existing services).
So are we really that awful and bad? Nope, I don't think so.
And yeah, that's pretty much how I'd spin it, if I was "Pottering". Thankfully though I am not. I am just some guy by the name of "Poettering", who happens to be involved in the project.
Lennart |
https://www.reddit.com/r/linux/comments/6jzz1g/ubuntu_security_notice_systemd_vulnerability/djixaui/ |
|
| Back to top |
|
|
zlg
Retired Dev
Joined: 11 Sep 2012
Posts: 49
Location: Earth
|
| Posted: Thu Jun 29, 2017 8:21 pm Post subject: |
|
|
That's some high quality spinning. I hope he greased the bearings in his chair first.  |
|
| Back to top |
|
|
Dominique_71
Veteran
Joined: 17 Aug 2005
Posts: 1890
Location: Switzerland (Romandie)
|
| Posted: Fri Jun 30, 2017 8:55 am Post subject: |
|
|
Before to ask for the number of bugs per sloc, one have to ask if he/she really need the functionality and want the payload provided by that software. As each user case is different, we will get a lot of different answers.
_________________
"Confirm You are a robot." - the singularity |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54577
Location: 56N 3W
|
| Posted: Fri Jun 30, 2017 9:44 am Post subject: |
|
|
... payload ...
That sounds like a virus.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
P.Kosunen
Guru
Joined: 21 Nov 2005
Posts: 309
Location: Finland
|
| Posted: Sat Jul 01, 2017 5:17 pm Post subject: |
|
|
| NeddySeagoon wrote: | | That sounds like a virus. |
| Quote: | | Trojan, is a malicious computer program which is used to hack into a computer by misleading users of its true intent. It works in system’s background and performs harmful actions there. Having it installed on your system means a great security risk for your PC and all the data, which is stored on it. |
Sounds like trojan horse to me. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sat Jul 01, 2017 5:25 pm Post subject: |
|
|
| A virus that installs a trojan. |
|
| Back to top |
|
|
rob_dot_p
n00b
Joined: 28 Jan 2017
Posts: 30
|
| Posted: Sun Jul 02, 2017 1:08 pm Post subject: |
|
|
https://github.com/systemd/systemd/issues/6237#issue-239378060
| Quote: | Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.
systemd will validate all configuration data you drop at it, making it hard to generate invalid configuration. Hence, yes, it's a feature that we don't permit invalid user names, and I'd consider it a limitation of xinetd that it doesn't refuse an invalid username.
So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid.
I hope that makes sense? |
| Quote: | | poettering added the not-a-bug label 3 days ago |
NOT
A
BUG |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Sun Jul 02, 2017 8:05 pm Post subject: |
|
|
| rob_dot_p wrote: | https://github.com/systemd/systemd/issues/6237#issue-239378060
| Quote: | Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.
systemd will validate all configuration data you drop at it, making it hard to generate invalid configuration. Hence, yes, it's a feature that we don't permit invalid user names, and I'd consider it a limitation of xinetd that it doesn't refuse an invalid username.
So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid.
I hope that makes sense? |
| Quote: | | poettering added the not-a-bug label 3 days ago |
NOT
A
BUG |
It's quite unfortunate that discussions on GitHub can be moderated in the ways they can be. The systemd developers seem to be using the moderation to insulate themselves from perfectly valid criticism. If they had to interact with each comment individually I think popular sentiment would be harder to ignore. It seems like most of the comments they claim are by trolls are actually topical.
Most systemd bugs seem to be closed with some explanation of what the bug is, conflating that explanation for a valid justification for the behavior. This one is particularly bad because relying on strtoul's return code for input validation is a particularly sophomoric trick that has no place in any program, and that's ignoring the fact they're making up standards to adhere to as they go along. |
|
| Back to top |
|
|
Mr. T.
Guru
Joined: 26 Dec 2016
Posts: 477
|
| Posted: Sun Jul 02, 2017 8:15 pm Post subject: https://github.com/systemd/systemd/issues/6237#issue-2393780 |
|
|
It is not a bug. Indeed, the process of verifying the configuration is in line with their expectations:
- An invalid identifier is ignored;
- an invalid configuration will be rejected.
In other words, only a (authentic) compliant service is authorized by systemd.
| Poettering wrote: | | In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. |
| Poettering wrote: | | systemd will validate all configuration data you drop at it, making it hard to generate invalid configuration. |
In practice, the potential vulnerability would be related to the executed service and not to the configuration file scan.
Last edited by Mr. T. on Sun Jul 02, 2017 8:17 pm; edited 1 time in total |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22626
|
| Posted: Sun Jul 02, 2017 8:17 pm Post subject: |
|
|
For the benefit of people who do not follow the link provided by rob_dot_p (or if the thread is later edited, since Github permits that):
A user reported a bug where systemd was given a .service file that specified to run the process as the unprivileged user 0day. Contrary to user expectations, systemd ran the program as root. The systemd maintainer rejected the report as not-a-bug. In my opinion, systemd found the one unacceptable solution out of the possible ways to handle this:- Run the program with an account other than specified in the systemd service file
- Run the program as the specified user
- Refuse to run the program, citing an error in the configuration.
Option (a) is dangerous if the program is not meant to run with privilege and the user does not notice the problem. Option (b) would be nice, but not strictly required since that is not a well-formed username (according to man useradd). Option (c) would be good because it would force the user to address the issue, either by renaming the account or by running the program as some other user. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
