RE: [gentoo-user] Inconsistent behavior in my Gentoo OS instance
Apologies for conflating the Wireshark related "bug / broken package / attack" comment with the bash issue. Good luck resolving the issues. -Original Message- From: Miroslav Rovis [mailto:miro.ro...@croatiafidelis.hr] Sent: Sunday, May 07, 2017 09:42 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance On 170505-22:40-0400, Bobby Kent wrote: > Looks like there are two things that concern you. Firstly, how bash > tab expansion appears to work (the ls, etc. commands executed when you > hit the tab key) on your system. Secondly, the "bash: unexpected EOF > while looking for matching `)'bash: syntax error: unexpected end of > file" messages generated when a particular tab expansion fails. > > Is that second issue generated by hitting tab at the end of the command: > > ls -1d root_170430_g0n*.d > > ? If so, perhaps there's something unusual with the items that match > the pattern "root_170430_g0n*.d*" that results in the error ... Well then there should have been somthing unusual with a plain rsync command and simple direcories in the link that I gave in other email, as I said in the mail to which the above is your reply, and which you quoted further below... > Regarding your diagnosis: > > > That's a serious bug or a serious malfunction in my Gentoo, the > > latter being most likely... > > > > And if it is the latter, it can only be one or the other way. > > One: the cause is in some Gentoo packge. > > Two: it is an attack by some unknown means. > > Before declaring But the whole paragraph originally, in the top of the thread (construing citation): > > Wireshark! Look at that! That's not a shadow. That's a serious bug > > or a serious malfunction in my Gentoo, the latter being most likely... And also in the abridged email it is under: > > Second issue > > So it refers to Wireshark only :) So pls. note that the above is not declaring it such about Bash... But I didn't modified the Bash completion. And esp. I would never modify it to be sed'ing and awk'ing on my /etc/ssh/ssh_config. ;-) ... So the above *could* apply to Bash, if I had (which I didn't) written it about Bash, but I would only word it to the level of suspicion. And suspicion it remains... > bug / broken package / attack, it might be an idea to see whether the > issue is reproducible, and under what circumstances. > > Note, tab expansion can be modified (see, for example, > http://www.linuxjournal.com/content/more-using-bash-complete-command). Which is a great link! Thanks! But again, while it could be some monkeys from space (of that kind of monkeys that write Bibles and so invent God[2], but these might be extraterrestrial monkeys, and maybe invisible, that can reach with their hands into computers without anybody realizing...). Oh, sorry for my irony. But this must have been something/someone with a purpose, that the purpose had been a prank/denial/subversion/... There is no event that can materialize out of nothing and without a cause, else physics and logic go to dusbin. And the event was pretty complex in this case. See below for the links to the script in action that I sent in the other email. And nobody expected that script to come to the fore. Thanks to Mr Linux[3], grsecurity in not widespread, and not so well known, and not even the shadows are familiar with all of its features. That script (in its action, I don't know where it resided in my machine[4]) only came to the fore because of the exec_logging feature of grsecurity-hardened kernel. Only because I had exec_logging turned on in my grsecurity-hardened kernel, I was able to show you the undeniable fact of what was executed at my hitting the Tab at that particular five or so seconds period of time in my real life. I need to remind the readers here that Bobby maybe refers here to what I gave in the other email, as I said I would (but the top posting that he uses, along with my peculiar slow and clumsy style, makes it a bit of a mess, sorry!). For my reference, see my quoted email further below, which I otherwise cut shorter. And from that other email I'm construing the links that I gave as if it was a reply, except for the links, I want them in the clear: > > Strange script planted with Bash https://www.croatiafidelis.hr/foss/cap/cap-170504-strange-bash/ > > should make for some thinking... > > It's in the logs > > ( https://www.croatiafidelis.hr/foss/cap/cap-170504-strange-bash/messages_1705 04_2155_g0n > > [link is at bottom of page, under "messages_170504_2155_g0n"] ). It has complicated further. On top of lots of time spent in analysis of my systems, I have had much difficulty connecting to the internet since I sent and posted on grsecurity.net and sent my messages to gentoo
RE: [gentoo-user] Inconsistent behavior in my Gentoo OS instance
Looks like there are two things that concern you. Firstly, how bash tab expansion appears to work (the ls, etc. commands executed when you hit the tab key) on your system. Secondly, the "bash: unexpected EOF while looking for matching `)'bash: syntax error: unexpected end of file" messages generated when a particular tab expansion fails. Is that second issue generated by hitting tab at the end of the command: ls -1d root_170430_g0n*.d ? If so, perhaps there's something unusual with the items that match the pattern "root_170430_g0n*.d*" that results in the error ... Regarding your diagnosis: > That's a serious bug or a serious malfunction in my Gentoo, the latter being most likely... > > And if it is the latter, it can only be one or the other way. > One: the cause is in some Gentoo packge. > Two: it is an attack by some unknown means. Before declaring bug / broken package / attack, it might be an idea to see whether the issue is reproducible, and under what circumstances. Note, tab expansion can be modified (see, for example, http://www.linuxjournal.com/content/more-using-bash-complete-command). -Original Message- From: Miroslav Rovis [mailto:miro.ro...@croatiafidelis.hr] Sent: Friday, May 05, 2017 01:02 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance Hi Bobby! Pls. see also: Tab (no exec) triggers script on Bash on grsec admin https://forums.grsecurity.net/viewtopic.php?f=3=4700 as well as the other email that I sent some 7 or so hours ago. NOTE: if I'm away, it's because I'm a little worried... I'm afraid my system may be vulnerable because of these issues. Patience pls. (no more but only my sig in bottom) On 170504-21:15-0400, Bobby Kent wrote: > Hi Miroslav, > > Attempting to reproduce third issue: > > # mkdir wibble1_1 > # mkdir wibble2_1 > # mkdir wibble3_1 > # mkdir wibble4_1 > # mkdir wibble5_1 > # for d in wibble*_1 ; do mkdir $d/wobble ; done # ls -1d wibble*_1 > wibble1_1 > wibble2_1 > wibble3_1 > wibble4_1 > wibble5_1 > > Then hit tab after positioning cursor after the / below: > # for i in $(ls -1d wibble*_1/) ; do echo $i ; done > > And the results are an attempt to autocomplete: > wibble1_1// wibble2_1// wibble3_1// wibble4_1// wibble5_1// > > Perhaps the test oversimplified the issue, though maybe you could > provide the simplest way to reproduce what you see. > > Thanks. > > > -Original Message- > From: Miroslav Rovis [mailto:miro.ro...@croatiafidelis.hr] > Sent: Tuesday, May 02, 2017 10:13 > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] Inconsistent behavior in my Gentoo OS > instance > > I've received one reply, and thanks again, but I had better remove the > gzip-"inconsistency" related bloat from my own previous email... I > need the previous text to make the remaining three important > parts/issues/inconsistencies clearer and easier to check, and reply > to, any of the three. > > I will also reorder my quotes to get them easier to skip or skip to, > since they are separate issues/inconsistencies. > > On 170501-18:17+0200, Miroslav Rovis wrote: > ... > First issue > === > (All first issue-related text have been removed here from all quotes > from my previous message) ... > > Second issue > > > Another part is actually on Wireshark mailing list. Pls. see: > > > > Filtering on (negated) frame.time_relative filters out wrong > > frame.number > > https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html > > as well as my study at: > > https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/gi > > t- > > devuan-mail-4.php > That page has just been updated with clearer instructions. > > > (and the previous ones there, but I gave the last as it is > > simplest/fastest to check) > > > > There is information that any advanced reader can easily provide by > > retracing some of my steps there, and which would clear some > > uncertainties > here. > ... > > ... That's a serious bug or a > > serious malfunction in my Gentoo, the latter being most likely... > > > > And if it is the latter, it can only be one or the other way. One: > > the cause is in some Gentoo packge. Two: it is an attack by some > > unknown > means. > > > > ( > > If Air-Gapped is some info, I did try and editcap (and the whole > > Wireshark) behave in the same wrong way in my Air-Gapped too. > > ... > > ) > > > > > Third issue > == > > The text it too much because the command line in which bash throw > strange error is a long f
RE: [gentoo-user] Inconsistent behavior in my Gentoo OS instance
Hi Miroslav, Attempting to reproduce third issue: # mkdir wibble1_1 # mkdir wibble2_1 # mkdir wibble3_1 # mkdir wibble4_1 # mkdir wibble5_1 # for d in wibble*_1 ; do mkdir $d/wobble ; done # ls -1d wibble*_1 wibble1_1 wibble2_1 wibble3_1 wibble4_1 wibble5_1 Then hit tab after positioning cursor after the / below: # for i in $(ls -1d wibble*_1/) ; do echo $i ; done And the results are an attempt to autocomplete: wibble1_1// wibble2_1// wibble3_1// wibble4_1// wibble5_1// Perhaps the test oversimplified the issue, though maybe you could provide the simplest way to reproduce what you see. Thanks. -Original Message- From: Miroslav Rovis [mailto:miro.ro...@croatiafidelis.hr] Sent: Tuesday, May 02, 2017 10:13 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Inconsistent behavior in my Gentoo OS instance I've received one reply, and thanks again, but I had better remove the gzip-"inconsistency" related bloat from my own previous email... I need the previous text to make the remaining three important parts/issues/inconsistencies clearer and easier to check, and reply to, any of the three. I will also reorder my quotes to get them easier to skip or skip to, since they are separate issues/inconsistencies. On 170501-18:17+0200, Miroslav Rovis wrote: ... First issue === (All first issue-related text have been removed here from all quotes from my previous message) ... Second issue > Another part is actually on Wireshark mailing list. Pls. see: > > Filtering on (negated) frame.time_relative filters out wrong > frame.number > https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html > as well as my study at: > https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git- > devuan-mail-4.php That page has just been updated with clearer instructions. > (and the previous ones there, but I gave the last as it is > simplest/fastest to check) > > There is information that any advanced reader can easily provide by > retracing some of my steps there, and which would clear some uncertainties here. ... > ... That's a serious bug or a > serious malfunction in my Gentoo, the latter being most likely... > > And if it is the latter, it can only be one or the other way. One: the > cause is in some Gentoo packge. Two: it is an attack by some unknown means. > > ( > If Air-Gapped is some info, I did try and editcap (and the whole > Wireshark) behave in the same wrong way in my Air-Gapped too. > ... > ) > Third issue == The text it too much because the command line in which bash throw strange error is a long for loop. The main point is marked with short new text below. > This is one of a series of commands that I used to check one of the > backups, in three different instances of tar-gzip'd archive I checked > (such as the /root directory tar-gzip'd today), and which showed > faultless upon decompression in all the three instances, despite the > three instances of tar-gzip'd archives not being identical (as their SHA256 sums show): > > # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed > 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed > 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file > in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> > ../$sum ; fi; done ; cd - ; done ; > > Now if I just place the cursor, by moving with Alt-F (skipping "words") and Ctrl-F (skipping 1 char) to just after: > > "for i in $(ls -1d root_170430_g0n*.d/" in that command, > > and if I then hit Tab for completion on the experssion there, I get > (and I'm sorry for the mess, but that's what I get): > > g0n ~ # for i in $(ls -1d root_170430_g0n*.dbash: unexpected EOF while > looking for matching `)'bash: syntax error: unexpected end of > file//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in > $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> > ../$sum ; fi; done ; cd - ; done ; > > NOTE (at proofreading time): rechecked, I do get that same behavior > the day after (wrote most of this yesterday, still to send this morning). > > [[ > NOTE (before delayed sending): In fact, it is only this clone that > exibits the above Bash malfunctioning. I just checked the same for > loop command (some six paragraphs above) in my Air-Gapped master [1] > (never any internet it sees, The [1] is important for understanding, especially this Bash issue in my Gentoo instance. Because in my Air-Gapped Gentoo instance that issue does not show at all. > longer workaround/detailed checking before updating it with stuff from > internet, sneakernet or optical media), and it is just fine. That > line, simply gave what it should: > > # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then
RE: [gentoo-user] Inconsistent behavior in my Gentoo OS instance
Regarding the fourth issue:
> g0n ~ # eix memtest86+
> * sys-apps/memtest86
> Available versions: 4.3.7 (~)4.3.7-r1 {serial}
> Homepage:http://www.memtest86.com/
> Description: A stand alone memory test for x86 computers
...
>
> Found 2 matches
> Received SIGSEGV - you probably found a bug in eix.
...
> Anyone else gets this too?
Not here (note the results of your "eix memtest86+" appears to be a match
for " eix memtest86" on my system):
# eix memtest86+
[I] sys-apps/memtest86+
Available versions: 2.01^t 4.00^t 4.20-r1 ~4.20-r3 5.01-r2 ~5.01-r3
{floppy iso serial}
Installed versions: 5.01-r2(11:23:03 AM 03/18/2017)(-floppy -iso
-serial)
Homepage:http://www.memtest.org/
Description: Memory tester based on memtest86
# eix memtest86
* sys-apps/memtest86
Available versions: 4.3.7 ~4.3.7-r1 {serial}
Homepage:http://www.memtest86.com/
Description: A stand alone memory test for x86 computers
[I] sys-apps/memtest86+
Available versions: 2.01^t 4.00^t 4.20-r1 ~4.20-r3 5.01-r2 ~5.01-r3
{floppy iso serial}
Installed versions: 5.01-r2(11:23:03 AM 03/18/2017)(-floppy -iso
-serial)
Homepage:http://www.memtest.org/
Description: Memory tester based on memtest86
Found 2 matches
#
