(2) grsecurity suspicious when HVR-3000 Composite attached
This is the Call Trace that I named: CallTrace_170827_064000_gdOv0. And I took it manually, so the stamp that I gave it approximates to 2017-08-27 6h 40m UTC (file CallTrace_170827_064000_gdOv0.txt listed bottom opening page).
[ 1889.957573] 0000000000000001 ffffc900093d79a0 0000000000000000 0000000000000000 [ 1889.959109] ffffc900093d79b8 ffffffff820ff0d9 0000000000000000 ffffc900093d7a38 [ 1889.960642] ffffffff813c0292 ffff880322dcf700 ffffffff81369b8e ffffffff81369b8e [ 1889.962197] Call Trace: [ 1889.962197] [] ? _raw_read_unlock+0x48/0x78 [ 1889.965236] [ ] ? start_this_handle+0x490/0x4c9 [ 1889.966728] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 1889.968197] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 1889.969624] [ ] __block_write_begin+0x4d/0x6d [ 1889.971028] [ ] ? __ext4_journal_start_sb+0x96/0xbe [ 1889.972449] [ ] ? __block_write_begin+0x4d/0x6d [ 1889.973852] [ ] ext4_da_write_begin+0x279/0x35f [ 1889.975237] [ ] generic_perform_write+0x177/0x30f [ 1889.976637] [ ] __generic_file_write_iter+0x103/0x352 [ 1889.978025] [ ] ? __generic_file_write_iter+0x103/0x352 [ 1889.979398] [ ] ext4_file_write_iter+0x253/0x53d [ 1889.982142] [ ] ? ext4_file_write_iter+0x253/0x53d [ 1889.983488] [ ] __vfs_write+0x109/0x155 [ 1889.984837] [ ] ? __vfs_write+0x109/0x155 [ 1889.986173] [ ] vfs_write+0xf4/0x178 [ 1889.987516] [ ] SYSC_write+0x7a/0xd2 [ 1889.988830] [ ] ? SYSC_write+0x7a/0xd2 [ 1889.990002] grsec: exec of /usr/bin/cut (cut -d: -f2- ) by /usr/bin/cut[rkhunter:27203] uid/euid: 0/0 gid/egid:0/0 parent ... [ 1889.992692] ... [ 1889.995423] [ ] rap_sys_write+0x44/0x64 [ 1889.996724] grsec: ... [ 1889.999373] [ ] entry_SYSCALL_64_fastpath+0x1e/0xec ... [ 1890.009200] [ ] entry_SYSCALL_64_fastpath+0x76/0xec [ 1890.010637] Code: 00 48 8b 45 b8 74 51 48 8b bd 60 ff ff ff 48 81 7f f8 62 0a fe 41 0f 85 fe 04 00 00 b9 01 00 00 00 48 89 c2 48 8b 75 98 4c 89 e7 <48> 8b 85 60 ff ff ff eb 0e 9e f5 01 be ff ff ff ff cc cc cc cc [ 1890.013774] RIP [ ] __block_write_begin_int+0x208/0x701 [ 1890.015304] RSP [ 1890.016790] CR2: ffffc900093d39d0 [ 1890.018277] ---[ end trace 4f6a9010996bf878 ]--- [ 1890.019754] Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root [ 1890.021281] Kernel Offset: disabled [ 1890.022783] ---[ end Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
Why did I copy this Call Trace manually? Because the previous crashes wouldn't be shown in any way, let alone recorded in the /var/log/syslog or /var/log/kern.log. There was nothing in the logs not even vaguely suggesting any clues (well, I have some work left to do with the rsyslog and logging... as well as an update and tweaking to my grsecurity-hardened kernel in my Devuan systems).
Just please have a look at the last that I got in /var/log/kern.log. The following are the previous to last line and the last line which contain the string rkhunter:27203 (which is the string found in what I manually copied above):
and:
( The huge number of lines is notorious for when grsecurity is logging rkhunter with exec_logging enabled. I generally prefer disabling it before rkhunter starts with issuing:
# echo 0 > /proc/sys/kernel/grsecurity/exec_logging
but I had missed doing it this time. )
But the last legible line of that /var/log/kern.log is:
after which there's only some binary garbage.
I presume that's when the halt by grsecurity came to effect...
Yes, I must be right about that, because the timing of my manually typed Call Trace above also suggests so. The timing of the (cut shorter):
[ 1889.990002] grsec: exec ... /usr/bin/cut[rkhunter:27203] ...
is just three seconds after:
Aug 27 06:40:33 gdOv kernel: [ 1886.863425] grsec: exec ... by /usr/bin/expr[rkhunter:24644] ...
Precisely 3s and 126ms:
$ echo 1889.990002-1886.863425 | bc 3.126577 $
and that looks real to me. Namely there is no picture to see of the screen at the time of that crash, and what I manually typed is now in no other way verifiable. Remember, they bricked my (stinking Schmoog spy-on-the-very-user-who-bought-it smartphone, now old model) Android Samsung Galaxy II.
There's one thing to notice about that Call Trace of morning of August 27th. Seeing I couldn't get any details of what the cause of the sudden trouble in my generally pretty calm and quiet, only solvable issues (pls. see Devuan forums, or Devuan DNG mailing list for more, or previously --and also in the future :-) again, God allowing -- Gentoo User mailing list, find me by Miroslav Rovis or my miroR username), sometimes even solved by me, for myself and for others.
The system would just crash and leave no written record of what happened... And then that morning, or the night before on the 26th, I decided to not start X, to see if that would help. And, I remember I recorded early that morning the boxing match Mayweather-McGregor to watch it later, and then I decided to archive it, since MTS/MP3 as I can tzap it from my HVR-3000 DVB-T versus H264/libvorbis makes three to four times less bytes in favor of the latter of course. And I had started this command, manually:
Aug 27 06:14:40 gdOv kernel: [ 333.726049] grsec: exec of /usr/bin/ffmpeg (ffmpeg -i RTL_H0827_0322_r.m2t -async 1 -ss 0 -map 0:v -c: libx264 -map 0:a -c:a libvorbis -vf scale=768:576,setsar=1:1,setdar=1) by /usr/bin/ffmpeg[nice:4815] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:4723] uid/euid:1000/1000 gid/egid:1000/1000
and I went to Church to Sunday Mass.
Once I came back after the Mass, I see just that trace on my monitor's screen...
I had also tried an hour earlier:
Aug 27 05:07:25 gdOv kernel: [670876.145008] grsec: exec of /usr/bin/ffmpeg (ffmpeg -i RTL_H0827_0322.m2t -async 1 -ss 0 -map 0:v -c: libx264 -map 0:a -c:a libvorbis -vf scale=768:576,setsar=1:1,setdar=16/) by /usr/bin/ffmpeg[nice:1581] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:4825] uid/euid:1000/1000 gid/egid:1000/1000
but it only crashed without a Call Trace left... You can really see already by the timing string having started anew, after
Aug 27 05:07:25 ... 670876.145008
counting anew:
Aug 27 06:14:4 ... 0333.726049
that there was a restart of the system... But that was only one of I think six or seven restarts in less than some 24 hours time, but don't remember exactly.
And I later got another trace, and this is how I copied it (file CallTrace_170827_200130_gdOv0.txt listed bottom opening page).
[ 6265.680157] [ 6265.681394] Oops: 0000 [#1] PREEMPT SMP [ 6265.682634] Modules linked in: [ 6265.68386 ] CPU: 3 PID: 6111 Comm: mencoder Not tainted 4.9.39-unofficial+grsec170817-19 #3 [ 6265.685122] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013 [ 6265.686420] task: ffff8802d9ed2a00 task.stack: ffffc900027c4000 [ 6265.687729] RIP: 0010:[] [ ] __block_write_begin_int+0x208/0x701 [ 6265.689067] RSP: 0018:ffffc900027c79f0 EFLAGS: 0010246 [ 6265.690388] RAX: ffff88019794a750 RBX: ffffea000654d600 RCX: 0000000000000001 [ 6265.691720] RDX: ffff88019794a750 RSI: 0000000000002c89 RDI: ffff8802e0bfbc68 [ 6265.693034] RBP: ffffc900027c7ae0 R08: ffff88019794a750 R09: ffff88019794a750 [ 6265.694340] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8802e0bfbc68 [ 6265.695650] R13: 0000000000002c89 R14: ffff8802e0bfbd20 R15: 0000000000000000 [ 6265.696954] FS: 0000036079da7040(0000) GS:ffff88032fd80000(0000) knlGS:0000000000000000 [ 6265.698266] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6265.699568] CR2: ffffc900027c3a40 CR3: 000000000279e000 CR4: 00000000000006f0 [ 6265.700875] Stack: [ 6265.702158] 0000000000000001 ffffc900027c7a10 0000000000000000 0000000000000000 [ 6265.703470] ffffc900027c7a28 ffffffff820ff0d9 0000000000000000 ffffc900027c7aa8 [ 6265.704774] ffffffff813c0292 ffff880320819b00 ffffffff81369b8e ffffffff81369b8e [ 6265.706083] Call Trace: [ 6265.707399] [ ] ? _raw_read_unlock=0x48/0x78 [ 6265.708738] [ ] ? start_this_handle+0x490/0x4c9 [ 6265.710091] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 6265.711454] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 6265.712820] [ ] __block_write_begin+0x4d/0x6d [ 6265.714190] [ ] ? ext4_journal_start_sb=0x96/0xbe [ 6265.715576] [ ] ? __block_write_begin+0x4d/0x6d [ 6265.716959] [ ] ? __ext4_get_inode_loc=0x7e9/0x7e9 [ 6265.718339] [ ] ext4_da_write_begin+0x279/0x35f [ 6265.719725] [ ] generic_perform_write+0x177/0x30f [ 6265.721053] [ ] __generic_file_write_iter+0x103/0x352 [ 6265.722342] [ ] ? __generic_file_write_iter+0x103/0x352 [ 6265.723638] [ ] ext4_file_write_iter+0x253/0x53d [ 6265.724925] [ ] ? ext4_file_write_iter+0x253/0x53d [ 6265.726208] [ ] __vfs_write+0x109/0x155 [ 6265.727478] [ ] ? __vfs_write+0x109/0x155 [ 6265.728743] [ ] vfs_write+0xf4/0x178 [ 6265.729994] [ ] SYSC_write+0x7a/0xd2 [ 6265.731231] [ ] ? SYSC_write+0x7a/0xd2 [ 6265.732460] [ ] rap_sys_write+0x44/0x64 [ 6265.733676] [ ] entry_SYSCALL_64_fastpath+0x1e/0xec [ 6265.734891] Code: 00 48 8b 45 b8 74 51 48 8b bd 60 ff ff ff 48 81 7f f8 62 0a fe 41 0f 85 fe 04 00 00 b9 01 00 00 00 48 89 c2 48 8b 75 98 4c 89 e7 <48> 8b 85 60 ff ff ff eb 0e 9e f5 01 be ff ff ff ff cc cc cc cc [ 6265.737433] RIP [ ] __block_write_begin_int+0x208/0x701 [ 6265.738627] RSP [ 6265.739800] CR2: ffffc900027c3a40
I copied it not knowing that I would have this one Call Trace in both kern.log and in syslog. What you can do is what I will do only now (I won't embelish anything, I am happy to be sincere) that I'm preparing this page. Open in one tab, or separate window, the manual trace and in another the kern.log trace. Align them using the mouse or scroll bar of your browser so that you can within fraction of a second with Alt-Tab or in some other way toggle the one and than the other to the fore. That is very likely an indication of the reliability of the first trace at the top of this page as well. Very few typoes I made! But I do have to emphasize that I did spend more time on manually copying of the evening's (20:01:30) trace than on the morning's one. Because it started dawning on me that I might figure out what was going on...
Indeed, now being August 28th late in the afternoon, and I've been writing just these pages this entire day, I can tell that since the crash of that last night's Call Trace there haven't been any more crashes, and my computer is on all of the time since (haven't gone online yet though).
No, it's late eveing of the 28th as I'm writing the finishing touches before publishing these pages.
One thing should not be missing by me to tell. How come I got the trace in the evening, but not in the morning, when it's the same system?
I got the evening trace because the system was just cloned afresh from the Air-Gapped master. So any eventual dirt from online, say in the caches of browsers or elsewhere, just wasn't there. And the system behaved. But pls., for that method, see those other places that will be linked to on the previous page or just search for Air-Gapping and cloning of systems.
Here is the same Call trace from /var/log/kern.log (file CallTrace_170827_200130_gdOv0_kern_log.txt):
[ 6265.673768] BUG: unable to handle kernel paging request at ffffc900027c3a40 [ 6265.676325] IP: [] __block_write_begin_int+0x208/0x701 [ 6265.677616] PGD 80000000027a9063 [ 6265.677635] PUD 323011063 [ 6265.678895] PMD 3210f9063 [ 6265.678905] PTE 0 [ 6265.680157] [ 6265.681394] Oops: 0000 [#1] PREEMPT SMP [ 6265.682634] Modules linked in: [ 6265.683862] CPU: 3 PID: 6111 Comm: mencoder Not tainted 4.9.39-unofficial+grsec170817-19 #3 [ 6265.685122] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013 [ 6265.686420] task: ffff8802d9ed2a00 task.stack: ffffc900027c4000 [ 6265.687729] RIP: 0010:[ ] [ ] __block_write_begin_int+0x208/0x701 [ 6265.689067] RSP: 0018:ffffc900027c79f0 EFLAGS: 00010246 [ 6265.690388] RAX: ffff88019794a750 RBX: ffffea000654d600 RCX: 0000000000000001 [ 6265.691720] RDX: ffff88019794a750 RSI: 0000000000002c89 RDI: ffff8802e0bfbc68 [ 6265.693034] RBP: ffffc900027c7ae0 R08: ffff88019794a750 R09: ffff88019794a750 [ 6265.694340] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8802e0bfbc68 [ 6265.695650] R13: 0000000000002c89 R14: ffff8802e0bfbd20 R15: 0000000000000000 [ 6265.696954] FS: 0000036079da7040(0000) GS:ffff88032fd80000(0000) knlGS:0000000000000000 [ 6265.698266] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6265.699568] CR2: ffffc900027c3a40 CR3: 000000000279e000 CR4: 00000000000006f0 [ 6265.700875] Stack: [ 6265.702158] 0000000000000001 ffffc900027c7a10 0000000000000000 0000000000000000 [ 6265.703470] ffffc900027c7a28 ffffffff820ff0d9 0000000000000000 ffffc900027c7aa8 [ 6265.704774] ffffffff813c0292 ffff880320819b00 ffffffff81369b8e ffffffff81369b8e [ 6265.706083] Call Trace: [ 6265.707399] [ ] ? _raw_read_unlock+0x48/0x78 [ 6265.708738] [ ] ? start_this_handle+0x490/0x4c9 [ 6265.710091] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 6265.711454] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 6265.712820] [ ] __block_write_begin+0x4d/0x6d [ 6265.714190] [ ] ? __ext4_journal_start_sb+0x96/0xbe [ 6265.715576] [ ] ? __block_write_begin+0x4d/0x6d [ 6265.716959] [ ] ? __ext4_get_inode_loc+0x7e9/0x7e9 [ 6265.718339] [ ] ext4_da_write_begin+0x279/0x35f [ 6265.719725] [ ] generic_perform_write+0x177/0x30f [ 6265.721053] [ ] __generic_file_write_iter+0x103/0x352 [ 6265.722342] [ ] ? __generic_file_write_iter+0x103/0x352 [ 6265.723638] [ ] ext4_file_write_iter+0x253/0x53d [ 6265.724925] [ ] ? ext4_file_write_iter+0x253/0x53d [ 6265.726208] [ ] __vfs_write+0x109/0x155 [ 6265.727478] [ ] ? __vfs_write+0x109/0x155 [ 6265.728743] [ ] vfs_write+0xf4/0x178 [ 6265.729994] [ ] SYSC_write+0x7a/0xd2 [ 6265.731231] [ ] ? SYSC_write+0x7a/0xd2 [ 6265.732460] [ ] rap_sys_write+0x44/0x64 [ 6265.733676] [ ] entry_SYSCALL_64_fastpath+0x1e/0xec [ 6265.734891] Code: 00 48 8b 45 b8 74 51 48 8b bd 60 ff ff ff 48 81 7f f8 62 0a fe 41 0f 85 fe 04 00 00 b9 01 00 00 00 48 89 c2 48 8b 75 98 4c 89 e7 <48> 8b 85 60 ff ff ff eb 0e 9e f5 01 be ff ff ff ff cc cc cc cc [ 6265.737433] RIP [ ] __block_write_begin_int+0x208/0x701 [ 6265.738627] RSP [ 6265.739800] CR2: ffffc900027c3a40 [ 6265.746219] ---[ end trace 467921bc5b68ead6 ]--- [ 6265.746224] grsec: banning user with uid 1000 until system restart for suspicious kernel crash
Note: to make the Call Trace recorded in the /var/log/kern.log (which does not differ in any single character from what is recorded in the /var/log/syslog) comparable with the manually typed one, I removed the leading Aug 27 17:57:14 gdOv kernel: from all the lines.
( All the lines start in the kern.log like this first line:
Aug 27 17:57:14 gdOv kernel: [ 6265.673768] BUG: unable to handle kernel paging request at ffffc900027c3a40
)
The only thing different now that I don't have any crashes, and yesterday and the day before with all those six or seven crashes alltogether (but I don't remember precisely) is:
The Composite input is now unplugged. I unplugged it after studying this last Call Trace, the "evening's" one.
Does that give an indication to me only in some fictitious way, am I just imagining so I can, say, play victim of these shadows, or is that a strong indication that others should objectively find to be a strong indication, namely especially the provider? (Not just a rethorical question, because I will try and see with the provider how come they are allowing somebody to play with my TV-card firmware through their IPTV service if it isn't their own personnel, since T-cogne notorious decidedly is for obnoxiously mischievous personnel and administrators.)
If only I will be able learn so much as to be able to undeniably prove whence exactly these nefarious activities against my system have come from... With the use of documented network traces, or PCAPs (along with screencasts to help explain the matter in lay terms to wider public).
But we are yet to see if in the PCAPs there is sufficient evidence on those packets that caused that
** (process:NNNN): WARNING **: Dissector bug, protocol SPDY, in packet XXXXX
If there is sufficient evidence in those PCAPs, and the traffic came from my providers addresses, and so the thing in those packets that messed up my Hauppauge HVR-3000 TV-cards came from my provider's addresses, wittingly or not, what then?
... What then?...
... What then? ...
... What then? ...
( echoing )
And on this issue, as I wrote in the disclaimer in the opening page, I really only have indications so far, not firm evidence (even though that evidence might be in the multiple, at different times, very sparse, PCAPs where those offending SPDY packets lie; but who says I will be able to understand the content of those very packets... and: how do I deal with them? when only reading them with Wireshark's tshark messed up my TV-cards firmware?)...
I don't think it's anything to do with Mencoder bugs either, even though there is mencoder mentioned:
CPU: 3 PID: 6111 Comm: mencoder Not tainted 4.9.39-unofficial+grsec170817-19 #3
in the evening's Call Trace. Rather, it was, I believe, some human trying to pown my system... because in the first Call Trace, the morning one that isn't in the logs, and which I got only after I didn't start X, and only printed on the screen with, after having powered off the machine, no lines in the log remaining about it, in that one it reads:
[ 1890.019754] Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
And that does look pretty serious. And grsecurity is such great protection!
But I also shouldn't forget to mention other strange things that I noticed.
The mobile that I use is a non-smart one. Deliberately. Either I will get to be free from the eavesdropping parasites, or, like it currently is the case, I, mostly, keep it away from where I am, and I don't carry it around. Because even these old ones got the necessary stinking evesdropping capabilities for the shadows and I believe also other nafarious uses they can achieve with them.
That some three years old non-smart mobile phone, when I started to have those crashes, I used to see what time it was in the day. Because electricity is expensive, and so I only run my computers if I need to work on them (and they are not power-thrifty at all. The machines that I use are both the power-hungry type (some two or three at least of each of the Abit AT8-32 and equally of the Asus Extreme4 are still working) both are AMD64, and especially the newer one was produced previously to the industry started going for greater efficiency and less electricity consumption...
And so I used the mobile to see the time of day. Otherwise I keep it really away from me, where it can't easily be used for taping and sending sound.
But not at sufficient distance, apparently.
There were times when I would here speakers, of the master Extreme4 machine that I clone this one that I will be posting these pages to my rented space from, buzz like when somebody calls you on the mobile.
Except there weren't any calls placed, when I looked it up...
And still maybe it was used in some other fashion, because at one time, and I couldn't anymore remeber in what exact circumstance, but it could only have been after some of the crashes, at one time I looked up the mobile, and while in probably many months or even a year or longer it never ever lost the date and time, previously, now, all of a sudden, and without me doing anything with it --I only looked up the time because my system had crashed-- all of a sudden the time was way back, probably factory defaults which is beginning of year 2011.
That could be and indication that the phone was somehow used for influencing whatever is being tried to do with my system.
---
