Discussion:
[ale] CRITICAL LINUX FLAW OPENS THE DOOR TO FULL ROOT ACCESS (RHE)
leam hall via Ale
2018-05-17 15:59:25 UTC
Permalink
only impacts RHEL and Fedora (and CentOS and Scientific Linux)
It's very specific in the way a script in NetworkManager handles
returning data from a DHCP server. The script runs as root and can be
overrun with remote shell commands. Oops.
"Ayer added that the situation is a reminder for Linux teams and developers of
the “frailty” of shell scripts. Shell, a commonly used programming language on
Linux systems, is simply prone to allowing these kinds of flaws to be coded, he
said."
I guess we should all take the hint and switch to something secure like, oh,
Java.
Grr..
Yeah, Ayer lost all credibility at that point.
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http:/
Jim Kinney via Ale
2018-05-21 00:56:13 UTC
Permalink
My gray beard head is doing pretty OK learning new stuff. Even systemd and docker and firewalld and selinux.

But, yeah, ansible is an all in one solution for running systems. So's spacewalk, and the odd collection of bash scripts I've accumulated over the years. I've seen systems controlled by git (ok. That was pretty cool).

Ever noticed how the solution to all problems is based on a solution provider's comfort tool? DBAs put everything in a database. Perl people use perl, java people (need therapy)..., etc.

ifconfig is deprecated and not installed by default having been replaced with ip. Does tons more, complicated syntax compared to ifconfig.

But, hey! What ever floats the boat that ships with permissions to see, use, modify, and redistribute the source code.
Yeah, if *I'd* said it, then it would have just been the ravings of a
graybeard scared-to-learn Linux wannabe poser systemd hater.
So I let others say it. And isn't it interesting that the botched
shellscript and systemd are from the same folks, and they're the folks
who have no problem at all with bringing complexity to GNU/Linux (soon
to be systemd/Linux).
SteveT
On Sun, 20 May 2018 18:32:21 -0400
A generic large tool to implement a simple task. Sounds like systemd
to me
:-)
Of course but that requires a run on ALL machines. By simply changing
ttl on the dhcp server to 5 minutes, waiting 24 hours, make the
change, wait 5 minutes, test, change ttl to 24 hours.
On Thu, 17 May 2018 13:47:33 -0400
On Thu, May 17, 2018 at 11:46:12AM -0400, DJ-Pfulio via Ale
In the article, they talk about servers and mysql ... who would
run
those on dhcp? Serious question - who and why?
In networks I've administered, everything but the DHCP server
and
the core routers has their (static!) addresses assigned via
DHCP.
+1
Makes network changes easy
Couldn't you accomplish the same thing using Puppet, Chef or
Ansible?
SteveT
Steve Litt
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28
_______________________________________________
Ale mailing list
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
Alex Carver via Ale
2018-05-20 17:13:35 UTC
Permalink
On Thu, 17 May 2018 13:47:33 -0400
In the article, they talk about servers and mysql ... who would run
those on dhcp? Serious question - who and why?
In networks I've administered, everything but the DHCP server and
the core routers has their (static!) addresses assigned via DHCP.
+1
Makes network changes easy
Couldn't you accomplish the same thing using Puppet, Chef or Ansible?
Only if those can also support microdevices (embedded systems) that do
not have clients available for those management packages. Tiny embedded
devices (like thermometers as an example) don't have much more than a
basic TCP/IP stack and just enough code to parse a DHCP packet.

A few embedded systems can manage some basic HTTP clients so if those
management packages can perform a replay script of some form
(interacting with the device as if it was a person on a terminal or
browser) then perhaps so.
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Steve Litt via Ale
2018-05-20 14:11:34 UTC
Permalink
On Thu, 17 May 2018 11:13:14 -0400
CRITICAL LINUX FLAW OPENS THE DOOR TO FULL ROOT ACCESS
^^^^^

Misleading headline. Redhat makes a mistake, and the headline blames all
of Linuxdom.

This threat is dangerous if you use Redhat, Fedora, CentOS and the
like, but the offending code doesn't exist in Linux or GNUtities, so if
you use Void, Devuan, Debian, Gentoo, Funtoo, etc, the bad code doesn't
exist on your machine.

Contrary to the headline, this is a **REDHAT** flaw.

SteveT

Steve Litt
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Solomon Peachy via Ale
2018-05-21 00:56:08 UTC
Permalink
So I let others say it. And isn't it interesting that the botched
shellscript and systemd are from the same folks, and they're the folks
who have no problem at all with bringing complexity to GNU/Linux (soon
to be systemd/Linux).
Nevermind this bug predates systemd's existence, isn't the first time
it's happened [1], and this particular issue (and the entire class)
wouldn't have occurred had systemd's networking infrastructure been in
use.

I get you don't like systemd, but please, stick to the actual facts?

[1] ISC DHCP has an extensive history of security holes [2] [3] [4] [5],
to say nothing of stuff distros have added to the pile.

[2] https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-17706/ISC-Dhcp.html
[3] https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-610/ISC-Dhcp-Client.html
[4] https://www.cvedetails.com/vulnerability-list/vendor_id-64/product_id-2017/ISC-Dhcpd.html
[5] Those lists are more than two years out of date; there have been at
least three more ISC DHCP CVEs since then, including two in 2018.

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
Joey Kelly via Ale
2018-05-21 22:05:10 UTC
Permalink
Post by Solomon Peachy via Ale
I get you don't like systemd, but please, stick to the actual facts?
Don't confuse me with facts.
--
Joey Kelly
Minister of the Gospel and Linux Consultant
http://joeykelly.net
504-239-6550
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Steve Litt via Ale
2018-05-22 20:54:59 UTC
Permalink
On Sun, 20 May 2018 20:56:08 -0400
Post by Solomon Peachy via Ale
So I let others say it. And isn't it interesting that the botched
shellscript and systemd are from the same folks, and they're the
folks who have no problem at all with bringing complexity to
GNU/Linux (soon to be systemd/Linux).
Nevermind this bug predates systemd's existence, isn't the first time
it's happened [1], and this particular issue (and the entire class)
wouldn't have occurred had systemd's networking infrastructure been
in use.
I get you don't like systemd, but please, stick to the actual facts?
Fact: The botched shellscript and systemd ARE from the same folks,
Redhat, just like I said. I was sticking to the facts.

Fact: I never said anything about which predated the other, but as long
as we're playing the predating game, this smoking gun predates systemd:

http://asay.blogspot.ru/2006/10/interview-with-red-hat-cto-brian.html

Complexity as a profit center, straight from the mouth of the then RH
CTO. We always knew about the means and opportunity, now we see, for a
FACT, the motive. Direct from a top Redhat exec. Perhaps if they'd spent
less juice complexifying systemd, they could have QA'ed their
shellscripts.

SteveT

Steve Litt
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Lightner, Jeffrey via Ale
2018-05-22 21:28:46 UTC
Permalink
From the original article:
"Red Hat has patched a vulnerability affecting the DHCP client packages that shipped with Red Hat Enterprise Linux 6 and 7."

RHEL6 does NOT have systemd though RHEL7 does. I think his "sticking to the facts" line was because you seemed to want to lay this at the feet of systemd just as many have done in the past with everything from dog mange to Obamacare. Not liking systemd is your right as is expressing that OPINION. Blaming things on systemd that have nothing to do with it just loses one credibility.

-----Original Message-----
From: Ale [mailto:ale-***@ale.org] On Behalf Of Steve Litt via Ale
Sent: Tuesday, May 22, 2018 4:55 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] CRITICAL LINUX FLAW OPENS THE DOOR TO FULL ROOT ACCESS (RHE)

On Sun, 20 May 2018 20:56:08 -0400
Post by Solomon Peachy via Ale
So I let others say it. And isn't it interesting that the botched
shellscript and systemd are from the same folks, and they're the
folks who have no problem at all with bringing complexity to
GNU/Linux (soon to be systemd/Linux).
Nevermind this bug predates systemd's existence, isn't the first time
it's happened [1], and this particular issue (and the entire class)
wouldn't have occurred had systemd's networking infrastructure been in
use.
I get you don't like systemd, but please, stick to the actual facts?
Fact: The botched shellscript and systemd ARE from the same folks, Redhat, just like I said. I was sticking to the facts.

Fact: I never said anything about which predated the other, but as long as we're playing the predating game, this smoking gun predates systemd:

http://asay.blogspot.ru/2006/10/interview-with-red-hat-cto-brian.html

Complexity as a profit center, straight from the mouth of the then RH CTO. We always knew about the means and opportunity, now we see, for a FACT, the motive. Direct from a top Redhat exec. Perhaps if they'd spent less juice complexifying systemd, they could have QA'ed their shellscripts.

SteveT

Steve Litt
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Steve Litt via Ale
2018-05-22 22:27:54 UTC
Permalink
On Tue, 22 May 2018 21:28:46 +0000
Post by Lightner, Jeffrey via Ale
"Red Hat has patched a vulnerability affecting the DHCP client
packages that shipped with Red Hat Enterprise Linux 6 and 7."
RHEL6 does NOT have systemd though RHEL7 does. I think his
"sticking to the facts" line was because you seemed to want to lay
^^^^^^
I guess it's in the eye of the beholder.
Post by Lightner, Jeffrey via Ale
this at the feet of systemd
My original post said:

=======================================================================
So I let others say it. And isn't it interesting that the botched
shellscript and systemd are from the same folks, and they're the
folks who have no problem at all with bringing complexity to
GNU/Linux (soon to be systemd/Linux).
=======================================================================

I laid the blame on Redhat, not on one of their software projects. And
I mentioned they're the same folks who gave us systemd. And in a later
post I mentioned that perhaps if they weren't spending a fortune on a
dev team for systemd, they might have found this bug earlier.
Post by Lightner, Jeffrey via Ale
everything from dog mange to Obamacare. Not liking systemd is your
right as is expressing that OPINION. Blaming things on systemd that
have nothing to do with it just loses one credibility.
I didn't blame systemd. I blamed Redhat, and brought up one of their
past bad acts.

SteveT

Steve Litt
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jim Kinney via Ale
2018-05-22 22:37:14 UTC
Permalink
please drop this. It's becoming annoying.
From the original article:"Red Hat has patched a vulnerability
affecting the DHCP clientpackages that shipped with Red Hat
Enterprise Linux 6 and 7."
RHEL6 does NOT have systemd though RHEL7 does. I think
his"sticking to the facts" line was because you seemed to want to
lay ^^^^^^I guess it's
in the eye of the beholder.
this at the feet of systemd
=====================================================================
==So I let others say it. And isn't it interesting that the botched
shellscript and systemd are from the same folks, and they're the
folks who have no problem at all with bringing complexity to
GNU/Linux (soon to be
systemd/Linux).======================================================
=================
I laid the blame on Redhat, not on one of their software projects.
AndI mentioned they're the same folks who gave us systemd. And in a
laterpost I mentioned that perhaps if they weren't spending a fortune
on adev team for systemd, they might have found this bug earlier.
everything from dog mange to Obamacare. Not liking systemd is
yourright as is expressing that OPINION. Blaming things on systemd
thathave nothing to do with it just loses one credibility.
I didn't blame systemd. I blamed Redhat, and brought up one of
theirpast bad acts.
SteveT
Steve Litt June 2018 featured book: Twenty Eight Tales of
Troubleshootinghttp://www.troubleshooters.com/28
_______________________________________________Ale mailing
ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/
Jim Kinney via Ale
2018-05-22 22:06:51 UTC
Permalink
Starting to sound more like a troll with each post on this. Might want
to step back and take long, slow, deep breath.
Of course the secret society _I'M_ in wrote a systemd plugin that scans
for specific usernames and promptly fails to start random portion based
on the database. Litt is in the database of course. Just cat
/proc/sys/kernel/shmmax_perf. Any value higher than 0 is the database
key value found. If the register doesn't show up at all, your ID is on
the list and you are blocked from ever having a working systemd
installation. Mark Shuttleworth personally signed off on this. I was
quite surprised.
So I let others say it. And isn't it interesting that the
botchedshellscript and systemd are from the same folks, and they're
thefolks who have no problem at all with bringing complexity
toGNU/Linux (soon to be systemd/Linux).
Nevermind this bug predates systemd's existence, isn't the first time
it's happened [1], and this particular issue (and the entire class)
wouldn't have occurred had systemd's networking infrastructure beenin
use.
I get you don't like systemd, but please, stick to the actual facts?
Fact: The botched shellscript and systemd ARE from the same
folks,Redhat, just like I said. I was sticking to the facts.
Fact: I never said anything about which predated the other, but as
longas we're playing the predating game, this smoking gun predates
http://asay.blogspot.ru/2006/10/interview-with-red-hat-cto-brian.html
Complexity as a profit center, straight from the mouth of the then
RHCTO. We always knew about the means and opportunity, now we see,
for aFACT, the motive. Direct from a top Redhat exec. Perhaps if
they'd spentless juice complexifying systemd, they could have QA'ed
theirshellscripts.
SteveT
Steve Litt June 2018 featured book: Twenty Eight Tales of
Troubleshootinghttp://www.troubleshooters.com/28
_______________________________________________Ale mailing
ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/
Steve Litt via Ale
2018-05-22 22:46:03 UTC
Permalink
On Tue, 22 May 2018 18:06:51 -0400
Post by Jim Kinney via Ale
Starting to sound more like a troll with each post on this.
True enough, but check out the first person mentioning systemd in this
thread.

Oops.

YOU were the one who threw out the "s word" and then stood back to
watch the predictable.

I can't blame you though. It was only a matter of time. Put Jeffrey,
Solomon and me on the same list and you're going to get a systemd
discussion. You just lit the fuse.

SteveT

Steve Litt
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Solomon Peachy via Ale
2018-05-22 23:33:55 UTC
Permalink
Post by Steve Litt via Ale
I can't blame you though. It was only a matter of time. Put Jeffrey,
Solomon and me on the same list and you're going to get a systemd
discussion. You just lit the fuse.
Going back to the original subject...

I remember RHL having a bug similar to this (ie improperly escaped shell
script arguuments in their DHCP client shell scripts) sometime in the
2000-2001 timeframe, that it was basically due to copy-pasting an ISC
example, and most other distos being independently affected. I also
recall that for some time afterwards, the ISC DHCP client's sample
scripts continued to be rife with similar bugs, and that there have been
a veritable laundty list of other security issues since then, including
two so far in 2018.

Blaming Red Hat for this one is deservedly fair, but let's not pretend
that ISC needs Red Hat's help to create exploitable security bugs in
their DHCP codebase.

That said, it's rather disingenuous to conflate this with anything to
with systemd, as yes, this bug predates systemd's existance, and in any
case does not involve the same individual contributors -- which brings
me to another point. Eeryone who's ever worked at Red Hat does not take
marching orders from some overarching cabal any more than you or I hold
the same opinions and motivations by virtue of subscribing to this
mailing list or (once upon a time) living in the Atlanta Metro area.

Meanwhile, if systemd makes everything RH has ever done or will do
irrecocably tainted, then you'd best get out of the Linux business
entirely, because RH is the single largest corportate contributor to
F/OSS in general -- not in the Google code dump over the wall manner,
but by directly making or otherwise sponsoring significant
upstream-first contributions to every layer of the stack [1], from the
Linux kernel itself; to core GNU utilities -- including and especially
GCC; to plumbing like KVM and container technologies; to rails,
servlets, and other application environments; to user applications like
LibreOffice. They also sponsor a ton of hardware enablement and related
infrastructure (networking, printing, graphics/compute, sound, plus
non-obvious things like ACPI, standardized firmware updating tools, and
refusing to support vendors that don't supply (and upstream) proper
drivers, which is really giving the various would-be ARM vendors
serious conniption fits!)

[1] https://community.redhat.com/software/

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
DJ-Pfulio via Ale
2018-05-17 17:17:17 UTC
Permalink
In the article, they talk about servers and mysql ... who would run
those on dhcp? Serious question - who and why?
In networks I've administered, everything but the DHCP server and the
core routers has their (static!) addresses assigned via DHCP.
Why?

_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Alan Dobkin via Ale
2018-05-17 17:27:58 UTC
Permalink
In the article, they talk about servers and mysql ... who would run
those on dhcp? Serious question - who and why?
In networks I've administered, everything but the DHCP server and the
core routers has their (static!) addresses assigned via DHCP.
Why?
I don't typically use DHCP to assign IP addresses to servers, but there
is certainly a management benefit to doing it that way if you have a lot
of them. For example, consider the case where you need to do a mass IP
change or change infrastructure like the gateway IP or DNS servers
across the board. With DHCP, it's as simple as making the change in one
place and then power-cycling the switch. Doing it manually could take
several hours otherwise. For host devices like servers and printers, I
would only use reserved IP addresses and assign very long lease time.
That way, DHCP traffic is minimal, and a DHCP server outage is pretty
much a non-issue.

Alan
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
DJ-Pfulio via Ale
2018-05-17 19:49:10 UTC
Permalink
Post by Alan Dobkin via Ale
In the article, they talk about servers and mysql ... who would run
those on dhcp? Serious question - who and why?
In networks I've administered, everything but the DHCP server and the
core routers has their (static!) addresses assigned via DHCP.
Why?
I don't typically use DHCP to assign IP addresses to servers, but there
is certainly a management benefit to doing it that way if you have a lot
of them. For example, consider the case where you need to do a mass IP
change or change infrastructure like the gateway IP or DNS servers
across the board. With DHCP, it's as simple as making the change in one
place and then power-cycling the switch. Doing it manually could take
several hours otherwise. For host devices like servers and printers, I
would only use reserved IP addresses and assign very long lease time.
That way, DHCP traffic is minimal, and a DHCP server outage is pretty
much a non-issue.
I've actually been though this. 4 easy commands per system. This was
back when NAT didn't exist. These days, I do it with an ansible
playbook/task.

Lots of ways to solve any issue. I've been burned a few times by DHCP
failures or misconfigurations.

Guess we each get to pick our poisons.
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Solomon Peachy via Ale
2018-05-17 17:29:02 UTC
Permalink
In networks I've administered, everything but the DHCP server and the
core routers has their (static!) addresses assigned via DHCP.
Why?
This way every system has its network parameters configured the same
way (automatically), which also provides a mechanism to change things
without having to touch every system.

(Eg deploying a new DNS or NTP server. Or using the DHCP custom
attributes for additional parameters.

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
Solomon Peachy via Ale
2018-05-17 17:30:08 UTC
Permalink
We used to do that with our Windows servers...the lease time was low...the
DHCP server went down one day...there was chaos shortly afterward...
A DHCP server is core critical infrastructure. There should not be only
one.

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
Ben Coleman via Ale
2018-05-17 22:00:35 UTC
Permalink
Post by Solomon Peachy via Ale
A DHCP server is core critical infrastructure. There should not be only
one.
Shirley, there's a Highlander joke in there somewhere.

Ben
--
Ben Coleman ***@benshome.net | For the wise man, doing right trumps
http://oloryn.benshome.net/ | looking right. For the fool, looking
Amateur Radio NJ8J | right trumps doing right.
William Bagwell via Ale
2018-05-18 01:30:42 UTC
Permalink
Post by Ben Coleman via Ale
Post by Solomon Peachy via Ale
A DHCP server is core critical infrastructure. There should not be only
one.
Shirley, there's a Highlander joke in there somewhere.
Ben
And now there is an Airplane joke.

I am serious...
--
William
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
H P Ladds via Ale
2018-05-22 14:06:32 UTC
Permalink
Post by William Bagwell via Ale
Post by Ben Coleman via Ale
Post by Solomon Peachy via Ale
A DHCP server is core critical infrastructure. There should not be only
one.
Shirley, there's a Highlander joke in there somewhere.
Ben
And now there is an Airplane joke.
I am serious...
Sure about that?
Post by William Bagwell via Ale
--
William
_______________________________________________
Ale mailing list
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Beddingfield, Allen via Ale
2018-05-17 17:39:45 UTC
Permalink
These days we have a full IPAM solution (BT Diamond) for DNS, DHCP, and
IP address inventory). It has multiple levels of redundancy at each
location, with each datacenter also being a failover for the other.
Allen B.
Post by Solomon Peachy via Ale
We used to do that with our Windows servers...the lease time was low...the
DHCP server went down one day...there was chaos shortly afterward...
A DHCP server is core critical infrastructure. There should not be only
one.
- Solomon
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
***@ua.edu
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets via Ale
2018-05-17 15:58:09 UTC
Permalink
There's no CVE number and they don't mention any other distributions.
Is this a Red Hat only issue? Seems unlikely.
CVE-2018-1111


https://thehackernews.com/2018/05/linux-dhcp-hacking.html
Raj Wurttemberg via Ale
2018-05-17 19:52:26 UTC
Permalink
Really?? I know that all of our network gear AND servers are static. I only
use DHCP on client and WiFi networks.

/Raj

-----Original Message-----
From: Ale <ale-***@ale.org> On Behalf Of Solomon Peachy via Ale
Sent: Thursday, May 17, 2018 1:13 PM
To: DJ-Pfulio <***@jdpfu.com>; Atlanta Linux Enthusiasts <***@ale.org>
Subject: Re: [ale] CRITICAL LINUX FLAW OPENS THE DOOR TO FULL ROOT ACCESS
(RHE)
In the article, they talk about servers and mysql ... who would run
those on dhcp? Serious question - who and why?
In networks I've administered, everything but the DHCP server and the core
routers has their (static!) addresses assigned via DHCP.

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
A. P. Garcia via Ale
2018-05-20 17:26:48 UTC
Permalink
Post by Raj Wurttemberg via Ale
Really?? I know that all of our network gear AND servers are static. I
only
Post by Raj Wurttemberg via Ale
use DHCP on client and WiFi networks.
We had a master list of IP<->MAC addresses, and that was used to
generate DNS/rDNS, DHCP tables, and kickstart configurations. No
hand-edited anything. No accidentally using someone else's address or
misconfiguring some other parameter.
It meant everything got set up the same way, and didn't rely on being
able to remotely access a system to make configuration changes
(ala ansible/etc) that tend to go along with taking a system out of test
into production. (or flaky BMCs or network KVM switches!)
- Solomon
Ah, that sounds like a DIY solution, and a rather good one! Would you care
to share any design or implementation decisions and details?

Thank you,
Phil Garcia
leam hall via Ale
2018-05-17 18:03:22 UTC
Permalink
Post by leam hall via Ale
"Ayer added that the situation is a reminder for Linux teams and
developers of the ???frailty??? of shell scripts. Shell, a commonly
used programming language on Linux systems, is simply prone to
allowing these kinds of flaws to be coded, he said."
Yeah, Ayer lost all credibility at that point.
No, he's completely correct. This flaw (and those of its class) would
not have been possible had that glue logic been implemented in just
about anything other than a shell script.
(That shell script basically took the DHCP results and used a shell
script to mash it up against a NetworkManager helper tool, which in
turn just makes a dbus invocation to notify NetworkManager of the
change. A more modern DHCP client would have just made the dbus call
directly)
That's like blaming PHP the language for bad web pages. If you don't
filter input you put yourself at risk. Ayers lost credibility since
the same flaw couple be implemented in most other languages.
_______________________________________________
Ale mailing list
***@ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Solomon Peachy via Ale
2018-05-17 19:04:53 UTC
Permalink
Post by leam hall via Ale
That's like blaming PHP the language for bad web pages. If you don't
filter input you put yourself at risk. Ayers lost credibility since
the same flaw couple be implemented in most other languages.
Oh, I absolutely blame PHP-the-language.

The language should make it easy to do things the Right Way, and more
difficult to do things badly. Shell and PHP are particularly bad in
that respect.

- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
Jim Kinney via Ale
2018-05-17 15:26:14 UTC
Permalink
If only they were using systemd's dhcp this would have never
happened! :-)
The linux laptop at the coffee shop is the big risk.
CRITICAL LINUX FLAW OPENS THE DOOR TO FULL ROOT ACCESS
(Threatpost)
https://threatpost.com/critical-linux-flaw-opens-the-door-to-full-roo
t-access/132034/
_______________________________________________
Ale mailing list
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/
Loading...