On Sun, 17 Jun 2018 at 03:18, Przemek Klosowski
<***@nist.gov> wrote:
[..]
I have mixed feelings about that. On one hand, I agree that this is NOT
a serious security issue (it's essentially a local compromise requiring
an existing local compromise), so if someone claims it'll make their
life easier, I want to say 'just do it'.
Przemek .. what you mean "this is NOT a serious security issue"?
Is it possible to be not serious pregnant?
Something IS security issue or NOT at all. Isn't it?
There are ONLY TWO possible states in context of security, and there
is nothing in the middle.
Do you know that on the beginning of the U*nix history buffer overflow
bugs or sniffing passwords in the network traffic have been named as
"not a serious security issue" as well for quite long time?
Prioritizing security issues is only possible in context of the RISK.
If today every BO or tmp directory content issue is wiped out
instantly on spot using raw fire I can tell you that RISK of
exploiting $PATH issues is far more greater than those tmp ones.
If only those /tmp issues are treated so seriously why $PATH issue
isn't something at least so dangerous like like those well known?
Because it is something neweis?
Because in case of /tmp issues there are still SIGNIFICANT number of
people remembering multi million loses by those issue and in case of
$PATH issues still no one can point on such cases discussed publicly.
In other words naming those issues as "NOT a serious security issue"
it is nothing more than oxymoron (phare with internal contradiction).
Problem with $PATH is really deep.
In Fedora like in all Linux distributions there is no clear
demarcation line between what should provide distribution for pure end
user who is going to use ONLY distribution resources and someone who
is more or less developer who is quite often working on the future
versions of some software which may even land sooner or later in the
Linux distribution.
What was in the past only temporary power user/developer kind of JFDI
solution which should not have any (especially permanent) impact those
from first group of the users started spreading .. and now IT
AFFECTS!!!
Many people without technical knowledge are probably assuming that
because using /usr/local was present OOTB so long, it cannot be so
dangerous (because if it were the case a long time ago, it would be
removed). Some people say that sometimes darkener place on the street
is just right under the street lamp and here is something very
similar.
This case is some diabolic mixture bad developers
behaviour/methodologies, "death by thousands of cuts" effect and even
crowd psychology.
Here is additional fact: there are few Unixes around which have no
/usr/local/{bin,sbin} paths in the OOTB $PATH and those Unixes are
using the same versions of the python or desktop software like on
Linuxes.
Today all this legacy or old development baggage which cause all this
is IMO today so absurd and at the same time is hard to understand by
even avg skilled Unix engineer.
Some time ago trying to explain the impact of this issue I was so
frustrated that I've thought that I must look during all those
explanations like one of those "purpurate cardinals" from classic
Monty Python sketch "No one expects The Spanish Inquisition!".
So after this I've started even calling this "new" class of security issues as:
"'No one expects The Spanish Inquisition' effect"
Generally, it is not only about $PATH, using env but as well checking
and using configuration files locations BEFORE using those package
binaries suppose to use OOTB configuration files.
Just try to have closer look on what prints below oneliner:
# strings /usr/{,s}bin/*| grep "^/" | egrep "bin|cfg|conf"|sort|uniq
Than you may try to extend this oneliner a bit to:
# strings /usr/{,s}bin/*| grep "^/" | egrep "bin|cfg|conf"|sort|uniq |
awk '{print $1}' | xargs rpm -qf
and right after this you may ask yourself: why so many are paths
hardcoded in so many files and are not owned by any package?
Someone with bad intentions will probably ask: how can I use checking
those cfg path or executing something from those paths to plug-in
something into **not changed OS distribution resources**?
Those outputs only encircles few possible swampy areas. I can tell
that I've already found more than few cases which really can be
exploited.
So far trying to investigate the impact of this (idiotic) "No one
expects The Spanish Inquisition effect" I found that it affects not
only all Linuxes or other U*nixes like Solaris, *BSD and other
flavours but in some rare cases even Windows.
My fiend checking Windows found for example that some Windows packages
installers are altering Windows system search path adding on the front
system env variable own base path and/or some base paths which this
software is not even using (and that is even more bizarre/odd).
This issue is so widely spread because all those OSesses are sharing
many pieces of source code.
I'm sure that sooner or later this will blow up straight into someone
face or will be used in some "binary attacks" which will be possible
to perform ONLY because all those legacy/devel/POC/JFDI modifications
are still around embedded into distribution software.
Because all those possibilities are so long opened it is possible that
some people already are using this as hacking platform.
So at the end .. do you still think that are all this risks is lower
than tmp issues???
Really?
And ad the end: if some exact packages have already embedded some
nasty possibilities, putting path from outside of the distribution on
the front of the $PATH is like almost embedding such possibility in
almost every possible distribution package.
Here is the example how to affect theoretically not affected program.
Just please add /usr/local/bin/id text file with content:
#!/bin/sh
echo "No one expects The Spanish Inquisition!"
exec /usr/bin/id $*
make this file executable and start gnome-terminal.
In other words: currently to execute something from /usr/local/bin no
one need to be conscious of trying such execution.
All this right now is possible because:
[***@domek demo]$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
^^^^^^^^^^^^^^ here
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/HH