I love all languages which do not require the ; So why bash, ksh and javascript listed? If you do one liners, you need the ; but on separate lines the newline does the job as well. Probably a reason why I may try to lean python. No ; there.
and this SMF may be coll and fancy, but it's a horrible headache for a "normal unix" sysadmin. Why can't it just be simple files? Oh no, we need a frontend to dump in and out unreadable XML data.
Same goes qith AIX and it's internal database hiding stuff from the users.
So finally every unix and linux has it's own, incompatible "I want to do horrible registry like windows" hack just because it's cool and hip, but it's not useable.
Does systemd present a virtual filesystem where you can edit text files with vi and get the thing configured? That would be one idea with which I could still use my beloved broadcast sed commands to change configs on 100 servers.
In unix world, this long known issue was only about the first filename. Typically with classig usage of tar, the first file is your archive, and all others are just filenames. unix/bsd treat them as filenames.
Now comes GNU getopt and "suddenly" decides that from now on it would be cool to have options anywhere on the command line. Result is that in GNU-world, tar is now vulnerable (and many many other commands) which had had no issue at all previously.
I would really like that getopt changes back to "if we see filenames, then consider being after --" or rather: stop parsing options if you find a parameter which does not match any option. That's the last one. Just stop there, do not continue. Leave the rest as it is.
the "first file in the list" problem is known to anyone doing unix since 30 years. What's new here is that now the option can hide anywhere in the list.
Funny: in unix, the -file is lexicographically globbed onto first position (- comes before a, typically LANG=C) in linux, you have some other oder... and it's first "a" then "-a" so the problem file does not come first. This would save one or the other exploit.... but getopt makes it so that the exploit works in any case.
it's not the bash problem the problem is that getopt gives tar that there is a parameter.... which is in fact a filename hidden somewhere deep in the file list.
tar cf archive.tar file1 file2 -v file3 # is verbose on linux, is NOT verbose on UNIX (complains about inexisting file "-v")
GNU is wrong, GNU broke the inherent security in options parsing by allowing options anywhere. GNU is insecure.
It will still work... as it did in the pre-GNU world of things. See this: UNIX (tries to archive file -v instead of becoming verbose): $ tar cf/tmp/a.tar a b -v tar: cannot stat -v. Not dumped.
LINUX (suddenly is verbose, thanks getopt): $ tar cf/tmp/a.tar a b -v a b
> If the first file name starts with a dash, how do you know it's a file name?
here all the other poster's arguments are valid. The first file being a -file has always been a concern in the unix world and programmers worked around that. But what's new with GNU, is that if you hid a command swithc in a long list of filenames, it won't be seen as a file but as a command switch. And that's where you shoot yourself in the foot. On old unix system this will never kill you: rm/tmp/file1/tmp/file2 * On linux, you are ready for losing all in you current directory's subdirs (or any other trickery of the original post)
no it does not The shell is not doing the -rf But it does the pipes, the rm does not do the pipes. So a pipe charater will not open a pipe And I also tested it, to be sure what I say.
This is because the linux commands do not respect what the manual says: man rm...
rm [OPTION]... FILE...
but in realitiy it's rather:
rm [OTION|FILE]...
whereas on other unix systems it works as expected, first the options, then the arguments HP-UX rm * rm: DIR1 directory
Solaris rm * rm: DIR1 directory
So screw the GNU tools, they mess things up for the "old unix sysadmins"
Here is a nice linux/unix trap: x=a y="rm z" f=$x $y
So you expect f to contain: a rm z not really... z: No such file or directory so the rm actually was executed
a=$x is an environment variable attribution, so $y becomes an executed command... And that one works on any unix/linux Recently patched in chkrootkit (CVE-2014-0476)
for years yes, but not for very long. Especially professionals have a very long software cycle, still hanging around with redhat5 and other old stuff. The bug was introduced in 1.01 and RH5 still runs 0.9.8 I have seen that a lot of times, bleeding edge may be cool, but not necessarily secure. Staying too far behind (into the non supported area) is not secure either. So the "one release back" strategy is not bad. In this aspect debian stable is a bit too up to date.
what bash? yes sure. just stay away from eval I'm currently checking if other constructs from bash are prone to execution or information disclosure. Came across 'declare' which may have an issue. Of course, SQL injections are possible, because SQL is not bash.
I checked. Running linux on the desktop since 16 years. So yeah, no news for me.
There will be no linux on the desktop, because the desktop dissapears. But there is already linux on the smartphone, if you say it's unix on the smartphone, then there are even more... and add all tablets into the mix.
yes, seriously. it's quite difficult to make bash execute input data. You'll need to pipe it into another shell instance or explicitly execute it with -c or eval. You don't believe that? prove me wrong!
so you want to explain space curving by a mass. And to do so you put a mass into a rubber sheet which is curved by earth gravity. Oh, nice, so to replace the gravity in your experiment you use... gravity. Means the curvature of spacetime is shown by using spacetime effects on the model. For me the thought experiment in itself is flawed. It's basically shifting dimensions, so our 3D becomes 2D and the spacetime becomes the 3rd dimension. Explaining what gravity is, it can't.
what is wrong? lf you don't know that, you cIearIly never have checked if your URL has the right letters for i and L Maybe use a pipe symbo| instead. Ok, it quite obvious here, but anyway, who designs a font with a word which renders like this: Illogical What about lIIl|I|llII|Il ?
tell that to my root kernel exploit I had during 6 months unpatched last year on my Mint laptop. That's a clear Mint fail. And there is no excuse for unstable or dangerous. I also never ever had an unstability via a new kernel, and I have run ubuntu since it started.
That's why I mostly stay away from mint Last year there was a linux root exploit in the kernel. I tried the exploit and it worked: bang root shell! So I waited to see when this would be fixed via the usual upgrade path... nothing happened during 6 months. Until I finally wanted to use my system and so I looked into the reasons why I'm still vulnerable while all other distributions are ok. So I need to run apt-get to get a new kernel! That's not "ready for the desktop".
Come on! All distributions are so proud to always say that fixes get quickly spread and there comes mint saying: "I won't even notify the end user that he should upgrade his X or kernel because it is vulnerable". That's dumb. Mint is wrong, Ubuntu is right. Result: I don't like Ubuntu, I don't like Mint. Is there a Mint derivative which does it correctly or do I need to go with Apple?
Slashdot Mirror
I put my closing parenthesis on a single line. Made the programs way shorter
( code
( more lisp
( some code
( finaly done
) ) ) )
Funny code, but it worked. Never had errors related to rearranging parenthesis like that.
I love all languages which do not require the ;
So why bash, ksh and javascript listed?
If you do one liners, you need the ; but on separate lines the newline does the job as well.
Probably a reason why I may try to lean python. No ; there.
and this SMF may be coll and fancy, but it's a horrible headache for a "normal unix" sysadmin.
Why can't it just be simple files? Oh no, we need a frontend to dump in and out unreadable XML data.
Same goes qith AIX and it's internal database hiding stuff from the users.
So finally every unix and linux has it's own, incompatible "I want to do horrible registry like windows" hack just because it's cool and hip, but it's not useable.
Does systemd present a virtual filesystem where you can edit text files with vi and get the thing configured? That would be one idea with which I could still use my beloved broadcast sed commands to change configs on 100 servers.
subway cars? come on!
And how many libraries of congress?
you are not precise on one point
In unix world, this long known issue was only about the first filename. Typically with classig usage of tar, the first file is your archive, and all others are just filenames. unix/bsd treat them as filenames.
Now comes GNU getopt and "suddenly" decides that from now on it would be cool to have options anywhere on the command line. Result is that in GNU-world, tar is now vulnerable (and many many other commands) which had had no issue at all previously.
I would really like that getopt changes back to "if we see filenames, then consider being after --" or rather: stop parsing options if you find a parameter which does not match any option. That's the last one. Just stop there, do not continue. Leave the rest as it is.
the "first file in the list" problem is known to anyone doing unix since 30 years.
What's new here is that now the option can hide anywhere in the list.
Funny: in unix, the -file is lexicographically globbed onto first position (- comes before a, typically LANG=C)
in linux, you have some other oder... and it's first "a" then "-a" so the problem file does not come first. This would save one or the other exploit.... but getopt makes it so that the exploit works in any case.
it's not the bash problem
the problem is that getopt gives tar that there is a parameter.... which is in fact a filename hidden somewhere deep in the file list.
tar cf archive.tar file1 file2 -v file3 # is verbose on linux, is NOT verbose on UNIX (complains about inexisting file "-v")
GNU is wrong, GNU broke the inherent security in options parsing by allowing options anywhere. GNU is insecure.
It will still work... as it did in the pre-GNU world of things. /tmp/a.tar a b -v
See this:
UNIX (tries to archive file -v instead of becoming verbose):
$ tar cf
tar: cannot stat -v. Not dumped.
LINUX (suddenly is verbose, thanks getopt): /tmp/a.tar a b -v
$ tar cf
a
b
> If the first file name starts with a dash, how do you know it's a file name?
here all the other poster's arguments are valid. The first file being a -file has always been a concern in the unix world and programmers worked around that. /tmp/file1 /tmp/file2 *
But what's new with GNU, is that if you hid a command swithc in a long list of filenames, it won't be seen as a file but as a command switch. And that's where you shoot yourself in the foot.
On old unix system this will never kill you: rm
On linux, you are ready for losing all in you current directory's subdirs (or any other trickery of the original post)
no it does not
The shell is not doing the -rf
But it does the pipes, the rm does not do the pipes.
So a pipe charater will not open a pipe
And I also tested it, to be sure what I say.
no the problem is with gnu tar...
it sees cf file file file --whatever
and it usese --whatever as option
on unix (not linux) it also sees cf file file --whatever
and tries to put the file "--whatever" into the tar archive.
linux (gnu) broke stuff which worked for ages in unix world
I just want to state the UNIX does not behave like that, it's GNU who does.
ordered ls:
LANG=C ls
this is the main problem cause: getopt messes it up, or something else in GNU
the oldschool unix systems do not behave that way. First the options, then the files.
This is because the linux commands do not respect what the manual says:
man rm...
rm [OPTION]... FILE...
but in realitiy it's rather:
rm [OTION|FILE]...
whereas on other unix systems it works as expected, first the options, then the arguments
HP-UX
rm *
rm: DIR1 directory
Solaris
rm *
rm: DIR1 directory
So screw the GNU tools, they mess things up for the "old unix sysadmins"
Here is a nice linux/unix trap:
x=a
y="rm z"
f=$x $y
So you expect f to contain: a rm z
not really...
z: No such file or directory
so the rm actually was executed
a=$x is an environment variable attribution, so $y becomes an executed command...
And that one works on any unix/linux
Recently patched in chkrootkit (CVE-2014-0476)
for years yes, but not for very long.
Especially professionals have a very long software cycle, still hanging around with redhat5 and other old stuff.
The bug was introduced in 1.01 and RH5 still runs 0.9.8
I have seen that a lot of times, bleeding edge may be cool, but not necessarily secure. Staying too far behind (into the non supported area) is not secure either.
So the "one release back" strategy is not bad. In this aspect debian stable is a bit too up to date.
what bash?
yes sure. just stay away from eval
I'm currently checking if other constructs from bash are prone to execution or information disclosure. Came across 'declare' which may have an issue.
Of course, SQL injections are possible, because SQL is not bash.
I checked. Running linux on the desktop since 16 years.
So yeah, no news for me.
There will be no linux on the desktop, because the desktop dissapears. But there is already linux on the smartphone, if you say it's unix on the smartphone, then there are even more... and add all tablets into the mix.
Had they asked if they believe in horoscope, the poll results would have been much better.
Funny poll:
* do you belive hroroscopes are scientific?
* do you believe astrology is scientific?
Rather an IQ test, to see who knows that astrology produces horoscopes.
yes, seriously.
it's quite difficult to make bash execute input data. You'll need to pipe it into another shell instance or explicitly execute it with -c or eval.
You don't believe that? prove me wrong!
so you want to explain space curving by a mass. And to do so you put a mass into a rubber sheet which is curved by earth gravity. Oh, nice, so to replace the gravity in your experiment you use... gravity. Means the curvature of spacetime is shown by using spacetime effects on the model.
For me the thought experiment in itself is flawed. It's basically shifting dimensions, so our 3D becomes 2D and the spacetime becomes the 3rd dimension. Explaining what gravity is, it can't.
what is wrong?
lf you don't know that, you cIearIly never have checked if your URL has the right letters for i and L
Maybe use a pipe symbo| instead.
Ok, it quite obvious here, but anyway, who designs a font with a word which renders like this: Illogical
What about lIIl|I|llII|Il ?
because one cannot distinguish between several characters which are just vertical bars
tell that to my root kernel exploit I had during 6 months unpatched last year on my Mint laptop. That's a clear Mint fail. And there is no excuse for unstable or dangerous.
I also never ever had an unstability via a new kernel, and I have run ubuntu since it started.
That's why I mostly stay away from mint
Last year there was a linux root exploit in the kernel. I tried the exploit and it worked: bang root shell!
So I waited to see when this would be fixed via the usual upgrade path... nothing happened during 6 months.
Until I finally wanted to use my system and so I looked into the reasons why I'm still vulnerable while all other distributions are ok.
So I need to run apt-get to get a new kernel! That's not "ready for the desktop".
Come on! All distributions are so proud to always say that fixes get quickly spread and there comes mint saying: "I won't even notify the end user that he should upgrade his X or kernel because it is vulnerable". That's dumb. Mint is wrong, Ubuntu is right.
Result: I don't like Ubuntu, I don't like Mint. Is there a Mint derivative which does it correctly or do I need to go with Apple?