Date: Tue, 5 Sep 2023 11:33:13 +0300 From: Sulev-Madis Silber <madis555@hot.ee> To: bob prohaska <fbsd@www.zefox.net> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: Stray characters in command history Message-ID: <CAEawv95DyP2p4L6amHdv5i0ioYD%2BabcnW%2BbKQKGazJDr8mZrnA@mail.gmail.com> In-Reply-To: <ZGplr9GJii3eI6RP@www.zefox.net> References: <ZGohbTVTRwfJkqyk@www.zefox.net> <ZGplr9GJii3eI6RP@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000005010290604987af2 Content-Type: text/plain; charset="UTF-8" i'm experiencing kind of similar issue. unsure why or how. i have 13.2. console is sc. the other side, via serial, is running current. uart is from usb serial adapter. other side has native soc uart. when i establish connection to that thing with cu, which is embedded board btw, and log in, i get weird random chars as if i've typed them in. if i do some input right after, i don't seem to get it. it gets worse, if i let cu run in other terminal and do some testing that involves lot of reboot cycles, while doing some tasks on other terminal, sometimes weird chars get injected into my input elsewhere. eg i run editor and it's annoying for something to appear as if i've typed it in. is it related? thankfully target isn't untrusted, otherwise it would be pretty bad? or where this thing even comes from? i know that you can do funny stuff with tiocsti and co but this looks pretty bad. both the fact that something makes it and the fact that they get injected elsewhere. there is also a some recent bug around this. so i'm not sure what to think of it all? On Sunday, May 21, 2023, bob prohaska <fbsd@www.zefox.net> wrote: > Here is another example, perhaps a bit clearer. > > The ssh connection to the first Pi3 in the chain had dropped, so it was > re-establishing via a regular user login, then su was invoked and tip run: > ..... > To change this login announcement, see motd(5). > Want to go the directory you were just in? > Type "cd -" > bob@pelorus:~ % su > Password: > # tip ucom > Stale lock on cuaU0 PID=2487... overriding. > connected > osed by r31 www s <<<< This appeared spontaneously, then I hit return. > osed: Command not found. <<<<< I didn't type anything. > bob@www:/usr/src % <<<<< The shell prompt on the 2nd Pi3's serial console. > .... > Clearly nothing to do with sshd, might it simply be a misdirected echo of console > output generated by a (dead or broken) tip connection? The first example looked > possibly malicious, this does not.... > > Thanks for reading, > > bob prohaska > > > > On Sun, May 21, 2023 at 06:49:33AM -0700, bob prohaska wrote: >> Lately I've been playing with buildworld on a Pi3 running -current. The same machine >> acts as a terminal server for a second Pi3 also running -current in my "cluster". >> I ssh into the first Pi3, su to root and run tip to pick up a serial connection to >> the second Pi's console. Both machines are within a week of up-to-date. >> >> While building world on the first Pi3 the ssh connection frequently drops and must be >> re-established. If there was a shell running on the serial console of the second >> Pi3 it typically keeps running and when the tip session is restarted disgorges a >> stream of accumulated console message. >> >> This morning the same thing happened, but I noticed something odd. The stream of >> messages (all login failure announcements from ssh) ended with >> >> .... >> May 21 06:15:00 www sshd[33562]: error: Fssh_kex_exchange_identification: banner line contains invalid characters >> *+May 21 06:15:19 www sshd[33565]: error: Fssh_kex_exchange_identification: Connection closed by remote host >> May 21 06:15:33 www sshd[33613]: error: Protocol major versions differ: 2 vs. 1 >> >> At that point I hit carriage return and got >> *+: No match. >> >> I did not type the *+ so it looks like the characters were somehow introduced elsewhere, >> possibly from the ssh failure message. How they got into the command stream is unclear. >> >> This strikes me as undesirable at best and possibly much worse. The shell reporting >> the "no match" was a regular user shell, but if I'd been su'd to root it appears that >> the unmatched characters would be seen by the root shell as input. >> >> This more-or-less fits with the pattern seen earlier with reboots observed via serial >> console halting on un-typed keystrokes. Those halts were attributed to electrical noise >> on the serial line, but this looks like something injected via part of the network >> login process. Reboot pauses have been an ongoing phenomenon for months, this is the >> first time I've noticed the "invalid characters" message from ssh on the console. >> >> Thanks for reading, apologies if I'm being a worrywart. >> >> bob prohaska >> >> >> > > --0000000000005010290604987af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i'm experiencing kind of similar issue. unsure why or how. i have 13.2.= console is sc. the other side, via serial, is running current. uart is fro= m usb serial adapter. other side has native soc uart. when i establish conn= ection to that thing with cu, which is embedded board btw, and log in, i ge= t weird random chars as if i've typed them in. if i do some input right= after, i don't seem to get it. it gets worse, if i let cu run in other= terminal and do some testing that involves lot of reboot cycles, while doi= ng some tasks on other terminal, sometimes weird chars get injected into my= input elsewhere. eg i run editor and it's annoying for something to ap= pear as if i've typed it in. is it related? thankfully target isn't= untrusted, otherwise it would be pretty bad? or where this thing even come= s from? i know that you can do funny stuff with tiocsti and co but this loo= ks pretty bad. both the fact that something makes it and the fact that they= get injected elsewhere. there is also a some recent bug around this. so i&= #39;m not sure what to think of it all?<br><br><br>On Sunday, May 21, 2023,= bob prohaska <<a href=3D"mailto:fbsd@www.zefox.net">fbsd@www.zefox.net<= /a>> wrote:<br>> Here is another example, perhaps a bit clearer.<br>&= gt;<br>> The ssh connection to the first Pi3 in the chain had dropped, s= o it was<br>> re-establishing via a regular user login, then su was invo= ked and tip run:<br>> .....<br>> To change this login announcement, s= ee motd(5).<br>> Want to go the directory you were just in?<br>> Type= "cd -"<br>> bob@pelorus:~ % su<br>> Password:<br>> # ti= p ucom<br>> Stale lock on cuaU0 PID=3D2487... overriding.<br>> connec= ted<br>> osed by r31 www s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<<= <=C2=A0 This appeared spontaneously, then I hit return.<br>> osed: Co= mmand not found.=C2=A0 <<<<< I didn't type anything.<br>= > bob@www:/usr/src %=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<<<< The= shell prompt on the 2nd Pi3's serial console.<br>> ....<br>> Cle= arly nothing to do with sshd, might it simply be a misdirected echo of cons= ole<br>> output generated by a (dead or broken) tip connection? The firs= t example looked<br>> possibly malicious, this does not....<br>><br>&= gt; Thanks for reading,<br>><br>> bob prohaska<br>><br>><br>>= ;<br>> On Sun, May 21, 2023 at 06:49:33AM -0700, bob prohaska wrote:<br>= >> Lately I've been playing with buildworld on a Pi3 running -cur= rent. The same machine<br>>> acts as a terminal server for a second P= i3 also running -current in my "cluster".<br>>> I ssh into = the first Pi3, su to root and run tip to pick up a serial connection to<br>= >> the second Pi's console. Both machines are within a week of up= -to-date.<br>>><br>>> While building world on the first Pi3 the= ssh connection frequently drops and must be<br>>> re-established. If= there was a shell running on the serial console of the second<br>>> = Pi3 it typically keeps running and when the tip session is restarted disgor= ges a<br>>> stream of accumulated console message.<br>>><br>>= ;> This morning the same thing happened, but I noticed something odd. Th= e stream of<br>>> messages (all login failure announcements from ssh)= ended with<br>>><br>>> ....<br>>> May 21 06:15:00 www ss= hd[33562]: error: Fssh_kex_exchange_identification: banner line contains in= valid characters<br>>> *+May 21 06:15:19 www sshd[33565]: error: Fssh= _kex_exchange_identification: Connection closed by remote host<br>>> = May 21 06:15:33 www sshd[33613]: error: Protocol major versions differ: 2 v= s. 1<br>>><br>>> At that point I hit carriage return and got<br= >>> *+: No match.<br>>><br>>> I did not type the *+ so it= looks like the characters were somehow introduced elsewhere,<br>>> p= ossibly from the ssh failure message. How they got into the command stream = is unclear.<br>>><br>>> This strikes me as undesirable at best = and possibly much worse. The shell reporting<br>>> the "no match= " was a regular user shell, but if I'd been su'd to root it ap= pears that<br>>> the unmatched characters would be seen by the root s= hell as input.<br>>><br>>> This more-or-less fits with the patt= ern seen earlier with reboots observed via serial<br>>> console halti= ng on un-typed keystrokes. Those halts were attributed to electrical noise<= br>>> on the serial line, but this looks like something injected via = part of the network<br>>> login process. Reboot pauses have been an o= ngoing phenomenon for months, this is the<br>>> first time I've n= oticed the "invalid characters" message from ssh on the console.<= br>>><br>>> Thanks for reading, apologies if I'm being a wo= rrywart.<br>>><br>>> bob prohaska<br>>><br>>>=C2=A0= <br>>><br>><br>> --0000000000005010290604987af2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEawv95DyP2p4L6amHdv5i0ioYD%2BabcnW%2BbKQKGazJDr8mZrnA>