Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: Xorg, pid: 3433) #20

Open
miroR opened this issue Dec 2, 2017 · 19 comments
Open

kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: Xorg, pid: 3433) #20

miroR opened this issue Dec 2, 2017 · 19 comments

Comments

@miroR
Copy link

miroR commented Dec 2, 2017 

Dec  1 23:21:10 gdOv kernel: [ 3413.024896] mrfw_dropIN=eth1 OUT= MAC=01:00:5e:00:00:01:24:9e:ab:ab:0b:b3:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=30291 PROTO=2 
Dec  1 23:22:33 gdOv kernel: [ 3496.150121] kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: Xorg, pid: 3433)
Dec  1 23:22:33 gdOv kernel: [ 3496.163060] BUG: unable to handle kernel paging request at ffffc9000c6ffb80
Dec  1 23:22:33 gdOv kernel: [ 3496.169720] IP: [<ffffc9000c6ffb80>] 0xffffc9000c6ffb80
Dec  1 23:22:33 gdOv kernel: [ 3496.176424] PGD 8000000002c31063 
Dec  1 23:22:33 gdOv kernel: [ 3496.176489] PUD 32300a063 
Dec  1 23:22:33 gdOv kernel: [ 3496.183192] PMD 2e32bb063 
Dec  1 23:22:33 gdOv kernel: [ 3496.183222] PTE 80000002d702b163
Dec  1 23:22:33 gdOv kernel: [ 3496.189987] 
Dec  1 23:22:33 gdOv kernel: [ 3496.196651] Oops: 0011 [#1] SMP
Dec  1 23:22:33 gdOv kernel: [ 3496.203281] CPU: 1 PID: 3433 Comm: Xorg Not tainted 4.9.65-unofficial+grsec171124-23 #1
Dec  1 23:22:33 gdOv kernel: [ 3496.210011] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013
Dec  1 23:22:33 gdOv kernel: [ 3496.210016] task: ffff88031b6fc380 task.stack: ffffc9000c6fc000
Dec  1 23:22:33 gdOv kernel: [ 3496.210024] RIP: 0010:[<ffffc9000c6ffb80>]  [<ffffc9000c6ffb80>] 0xffffc9000c6ffb80
Dec  1 23:22:33 gdOv kernel: [ 3496.210027] RSP: 0018:ffffc9000c6ffb70  EFLAGS: 00010283
Dec  1 23:22:33 gdOv kernel: [ 3496.210031] RAX: 0000000000000000 RBX: ffff8802d1b0bc68 RCX: ffffffff81a3e74e
Dec  1 23:22:33 gdOv kernel: [ 3496.210034] RDX: 000000000000003e RSI: 00000000000000fe RDI: ffff8802bab77c80
Dec  1 23:22:33 gdOv kernel: [ 3496.210036] RBP: ffffc9000c6ffb68 R08: ffff8802c2d20b20 R09: ffff8802bab77c00
Dec  1 23:22:33 gdOv kernel: [ 3496.210039] R10: ffff8802bab77c20 R11: ffff8802c2d20b20 R12: 0000000000000002
Dec  1 23:22:33 gdOv kernel: [ 3496.210041] R13: ffff880320180740 R14: ffff8802d1b0bc68 R15: ffff880320154c00
Dec  1 23:22:33 gdOv kernel: [ 3496.210047] FS:  0000036130345a80(0000) GS:ffff88032fc80000(0000) knlGS:0000000000000000
Dec  1 23:22:33 gdOv kernel: [ 3496.210067] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec  1 23:22:33 gdOv kernel: [ 3496.210070] CR2: ffffc9000c6ffb80 CR3: 0000000002c22000 CR4: 00000000000006f0
Dec  1 23:22:33 gdOv kernel: [ 3496.210072] Stack:
Dec  1 23:22:33 gdOv kernel: [ 3496.210082]  ffffffff81a3e74e ffff8802d1b0bc98 ffffc9000c6ffbd0 ffffffff81a40c93
Dec  1 23:22:33 gdOv kernel: [ 3496.210089]  ffffffffffff4111 00ffffffffff4111 f8f834b34e9287a1 ffffc9000c6ffbf8
Dec  1 23:22:33 gdOv kernel: [ 3496.210095]  ffff880320161800 ffff88031dffff30 ffff88031dfffe60 ffff880320161800
Dec  1 23:22:33 gdOv kernel: [ 3496.210097] Call Trace:
Dec  1 23:22:33 gdOv kernel: [ 3496.210110]  [<ffffffff81a3e74e>] ? ttm_bo_cleanup_memtype_use+0xce/0x120
Dec  1 23:22:33 gdOv kernel: [ 3496.210117]  [<ffffffff81a40c93>] ? ttm_bo_release+0x2c3/0x370
Dec  1 23:22:33 gdOv kernel: [ 3496.210123]  [<ffffffff81a40d87>] ? ttm_bo_unref+0x47/0x70
Dec  1 23:22:33 gdOv kernel: [ 3496.210131]  [<ffffffff81a7afa3>] ? radeon_bo_unref+0x53/0xb0
Dec  1 23:22:33 gdOv kernel: [ 3496.210138]  [<ffffffff81a986ff>] ? radeon_gem_object_free+0x8f/0xd0
Dec  1 23:22:33 gdOv kernel: [ 3496.210146]  [<ffffffff81a04d81>] ? drm_gem_object_free+0x61/0x100
Dec  1 23:22:33 gdOv kernel: [ 3496.210154]  [<ffffffff81a05a4f>] ? drm_gem_object_unreference_unlocked+0x7f/0x130
Dec  1 23:22:33 gdOv kernel: [ 3496.210161]  [<ffffffff81a05bad>] ? drm_gem_object_handle_unreference_unlocked+0xad/0x140
Dec  1 23:22:33 gdOv kernel: [ 3496.210168]  [<ffffffff81a05cee>] ? drm_gem_object_release_handle+0xae/0x140
Dec  1 23:22:33 gdOv kernel: [ 3496.210175]  [<ffffffff81a05e2f>] ? drm_gem_handle_delete+0xaf/0x140
Dec  1 23:22:33 gdOv kernel: [ 3496.210182]  [<ffffffff81a05f8a>] ? drm_gem_close_ioctl+0x5a/0x90
Dec  1 23:22:33 gdOv kernel: [ 3496.210188]  [<ffffffff81a07c1f>] ? drm_ioctl+0x31f/0x6c0
Dec  1 23:22:33 gdOv kernel: [ 3496.210195]  [<ffffffff81a05f30>] ? drm_gem_dumb_destroy+0x70/0x70
Dec  1 23:22:33 gdOv kernel: [ 3496.210204]  [<ffffffff81a4f052>] ? radeon_drm_ioctl+0x82/0x100
Dec  1 23:22:33 gdOv kernel: [ 3496.210211]  [<ffffffff813120d2>] ? do_vfs_ioctl+0xf2/0xb40
Dec  1 23:22:33 gdOv kernel: [ 3496.210218]  [<ffffffff81312c76>] ? rap_sys_ioctl+0x76/0xe0
Dec  1 23:22:33 gdOv kernel: [ 3496.210225]  [<ffffffff825ad653>] ? entry_SYSCALL_64_fastpath+0x1e/0xec
Dec  1 23:22:33 gdOv kernel: [ 3496.210297] Code: 00 00 00 83 02 01 00 00 00 00 00 70 fb 6f 0c 00 c9 ff ff 18 00 00 00 00 00 00 00 4e e7 a3 81 ff ff ff ff 98 bc b0 d1 02 88 ff ff <d0> fb 6f 0c 00 c9 ff ff 93 0c a4 81 ff ff ff ff 11 41 ff ff ff 
Dec  1 23:22:33 gdOv kernel: [ 3496.210302] RIP  [<ffffc9000c6ffb80>] 0xffffc9000c6ffb80
Dec  1 23:22:33 gdOv kernel: [ 3496.210304]  RSP <ffffc9000c6ffb70>
Dec  1 23:22:33 gdOv kernel: [ 3496.210306] CR2: ffffc9000c6ffb80
Dec  1 23:22:33 gdOv kernel: [ 3496.234789] ---[ end trace 5a75a1db89292227 ]---
Dec  1 23:22:33 gdOv kernel: [ 3496.234793] grsec: banning user with uid 1000 until system restart for suspicious kernel crash
Dec  1 23:22:33 gdOv kernel: [ 3496.320858] grsec: (root:U:/bin/bash) special role admin (id 1) exited by /bin/bash[bash:3667] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:3666] uid/euid:0/0 gid/egid:0/0
Dec  1 23:22:33 gdOv kernel: [ 3496.320968] grsec: (root:U:/bin/bash) special role admin (id 2) exited by /bin/bash[bash:7282] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:7281] uid/euid:0/0 gid/egid:0/0
Dec  1 23:22:33 gdOv kernel: [ 3496.336492] grsec: (root:U:/sbin/agetty) exec of /sbin/agetty (/sbin/getty 38400 tty6 ) by /sbin/agetty[init:10537] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Dec  1 23:22:59 gdOv kernel: [ 3522.377686] sky2 0000:06:00.0 eth1: Link is down
@miroR
Copy link
Author

miroR commented Dec 2, 2017 •
edited
Loading

Again, my time online is minimal, always traced (but working on PCAPs is many many times multiple than the time online, for non-experts)...
And, just for the less expert than me visiting here, these all (likely, pls. correct me if I'm wrong) troffeys of grsec-unoff. Troffeys, not failures.
And I'm making two posts, so not to lose the first post, as often the attacks happen right, or soon, affer I come online.

@theLOICofFRANCE
Copy link

@miroR
Hi,

If you want us to help you, you will have to avoid opening any exits at all times and perform the tasks you are asked to do so that we can diagnose your problem or even ideally reproduce it.

1] minipli asked you to try with a recent kernel (4.14.4). Have you tried?
2] SKY2 just lost the connection without crashing. This could be due to your router, an outdated software that uses promiscuous mode, or one of your scripts.
3] Update your bios (version 2.80) that might fix the NX warn.

Regards,

@miroR
Copy link
Author

miroR commented Dec 7, 2017 via email

@miroR
Copy link
Author

miroR commented Dec 8, 2017

I have stressed the system, this clone that I use for online, without sparing it since my last night's post. E.g. FFmpeg, which by default runs with all processing power, has been on since I went to sleep very early, minutes into this day (UTC), and it's still churning on videos. Will be lots of garbage videos to clean, because I recorded mostly indiscriminately, to record a lot for testing purposes.

And also mencoder was recording on Hauppauge HVR3000 composite input all the time (lot of garbage, indiscriminately).

And so was tzap (same note). I promised I would post the scripts:

$ cat /usr/local/bin/tzap-cat-g0.sh 
#!/bin/bash
#
# This script is run e.g.:
# tzap-cat.sh "Nova TV" Nova
# as normal user.
# Run this in a dir where you have all the perms, and where you record your channels.
# Can only be (other that this script with tzap in its name) one tzap running:
ps aux | grep -v tzap-cat | grep [t]zap | awk '{ print $2 }' > tzap.pid 
echo cat tzap.pid
cat tzap.pid
#read FAKE
# and likely cat you mostly use to temporary stuff, such as quick look at text
# files, else getting the right pid of cat may be problematic:
ps aux | grep -v tzap-cat | grep [c]at | awk '{ print $2 }' > cat.pid 
echo cat cat.pid
cat cat.pid
#read FAKE
# (The above may not be the best way to do it, but is the way that I know.)
tzap_pid=$(cat tzap.pid)
kill $tzap_pid 
echo cat tzap.pid
cat tzap.pid
#read FAKE
cat_pid=$(cat cat.pid)
kill $cat_pid 
echo cat cat.pid
cat cat.pid
#read FAKE
echo "Next Enter tzaps the $0 $1 $2 (one more to cat-record)"
#read FAKE
# Change this if your adapter is not the second as below, and also not dvr1 but
# dvr0 (whatever dvr stand for; digital video record ?). The case below is such
# because my old Hauppauge HVR-3000 is the second card, and the -d1 is for the
# DVB-T (DVB-S being at dvr0).
# The $1 must be the name of the channel as in your:
# /home/<you>/.mplayer/channels.conf
tzap -a0 -f1 -d1 -r "$1" & tzap_pid=$! 
echo $tzap_pid
echo "Next Enter cat-records the $0 $1 $2"
#read FAKE
# This line above, the the one below are actually not used the next time this
# script is run, getting the pids (this script gets the pids anew instead), to
# maybe kill this tzap/cat session, and start another one, usually on a
# different channel:
echo $tzap_pid > tzap.pid
# and this does the recording (the $2 really could be modified from $1, turning
# ' ' into '_'), but, no time):
ts=$(date +H%m%d_%H%M) #[t]ime[s]tamp
sleep 3 && cat /dev/dvb/adapter0/dvr1 > ${2}_${ts}.m2t & cat_pid=$!

And:

$ cat /usr/local/bin/tzap-cat-kill.sh 
#!/bin/bash
ps aux | grep -E 'tzap|cat' | awk '{ print $2 }'
echo "hit Enter"
#read FAKE
ps aux | grep -E '[t]zap|[c]at' | awk '{ print $2 }'
echo "hit Enter"
#read FAKE
for i in $(ps aux | grep -E '[t]zap|[c]at' | awk '{ print $2 }'); do
        kill -9 $i;
done ;
$

Just in case... I don't think anything causing issues to be found in these (primitive) scripts.

And lots of mplayer runs. Lot's of. E.g. with a command line like this:

for i in $(ls -1 *.mkv|sed 's/\.mkv//'|grep Compo); do ls -l $i.avi $i.mkv; midentify $i.avi|egrep 'FILENAME|LENG'; midentify $i.mkv|egrep 'FILENAME|LENG'; echo mplayer -osdlevel 3 -geometry 0:0 -speed 2 $i.avi; read FAKE; mplayer -osdlevel 3 -geometry 0:0 -speed 2 $i.avi; echo mplayer -osdlevel 3 -geometry 200:0 -speed 1 $i.mkv; read FAKE; mplayer -osdlevel 3 -geometry 200:0 -speed 1 $i.mkv; ask; if [ "$?" == 0 ]; then mv -iv $i.mkv OK/ && rm -v $i.avi; read FAKE; fi; done;

That script lists every Compo_NNNNNN_NNNN.avi file (where NNNNNN_NNNN can be, say 171208_0659, the timestamp, because I run mencoder on Composite input with:


mencoder tv:// -profile mpeg4_capt_HaupP -o Compo_`date +H%m%d_%H%M`.avi

where I have this config:


$ cat ~/.mplayer/mencoder.conf  | grep -A09 '\[mpeg4_capt_HaupP]' 
[mpeg4_capt_HaupP]
profile-desc="mpeg4 capture"
tv=input=1:driver=v4l2:device=/dev/video0:normid=3:input=1:alsa=1:adevice=hw.2,0:audiorate=48000:amode=1:width=768:height=576
ovc=lavc=1
lavcopts=vcodec=mpeg4:autoaspect=1:vqscale=4:vb_strategy=1:vmax_b_frames=2:mbd=0:turbo=1
vf=softskip,harddup
mc=0
noskip=1
oac=mp3lame=1
#lameopts=cbr=1:preset=standard

I actually ran strace on:


$ ls -ltr ~/strace.d/tzap-cat-*  ~/strace.d/mplayer_171206_1*   ~/strace.d/mencoder_17120* | tail -7
-rw-r--r-- 1 mr mr   425198 2017-12-06 17:30 /home/mr/strace.d/mplayer_171206_173001
-rw-r--r-- 1 mr mr    34461 2017-12-06 17:30 /home/mr/strace.d/tzap-cat-g0.sh_171206_173004
-rw-r--r-- 1 mr mr   416603 2017-12-06 17:30 /home/mr/strace.d/mplayer_171206_173011
-rw-r--r-- 1 mr mr  1366221 2017-12-06 17:59 /home/mr/strace.d/mencoder_171206_175909
-rw-r--r-- 1 mr mr   840610 2017-12-06 17:59 /home/mr/strace.d/mencoder_171206_175941
-rw-r--r-- 1 mr mr 76842985 2017-12-06 18:35 /home/mr/strace.d/mencoder_171206_180001
-rw-r--r-- 1 mr mr    71710 2017-12-07 17:10 /home/mr/strace.d/mencoder_171207_171029

I doubt there is anything to be found in there...

Also the old 27.4.0 Pale Moon is on all the time. It crashed, but that was restrected to it only. It's probably just some kind of problem with the addons not behaving as PAX would like:


Dec  8 00:03:13 gdOv kernel: [25162.961621] grsec: (mr:U:/usr/bin/sudo) exec of /usr/bin/sudo (sudo -s kill 8237 8239 8240 ) by /usr/bin/sudo[uncenz-kill:8416] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/local/bin/uncenz-kill[uncenz-kill:8386] uid/euid:1000/1000 gid/egid:1000/1000
Dec  8 00:03:13 gdOv kernel: [25162.976127] grsec: (root:U:/bin/bash) exec of /bin/bash (/bin/bash -c kill 8237 8239 8240 ) by /bin/bash[sudo:8417] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:8416] uid/euid:0/0 gid/egid:0/0
Dec  8 00:07:54 gdOv kernel: [25443.915858] PAX: execution attempt in: <stack>, 38aa8d43000-38aa8d68000 3fffffda000
Dec  8 00:07:54 gdOv kernel: [25443.915867] PAX: terminating task: /usr/lib/palemoon/palemoon(palemoon):8266, uid/euid: 1000/1000, PC: 0000038aa8d61a20, SP: 0000038aa8d60418
Dec  8 00:07:54 gdOv kernel: [25443.915875] PAX: bytes at PC: b8 78 b3 b2 5c 03 00 00 00 1a d6 a8 8a 03 00 00 00 00 00 00 
Dec  8 00:07:54 gdOv kernel: [25443.915885] 
Dec  8 00:07:54 gdOv kernel: [25443.915886] PAX: bytes at SP-8: 0000035cdf946c85 0000035cdf94c8a8 0000035cb2b378d0 0000038aa8d60c08 0000035ca931a128 0000038aa8d60850 0000035cb2b378d0 0000038aa8d604d0 0000038aa8d60510 0000000000000083 0000035cd1ce7600 
Dec  8 00:07:54 gdOv kernel: [25443.915892] 
Dec  8 00:07:54 gdOv kernel: [25443.916286] grsec: (mr:U:/usr/lib/palemoon/palemoon) denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/lib/palemoon/palemoon[palemoon:8266] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3537] uid/euid:1000/1000 gid/egid:1000/1000

On the standard input (because in my lean OpenBox, I start programs from xterm, I had:


mr@gdOv:~$ 1512691451901        addons.update-checker   WARN    Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&[email protected]&version=1.13.0&maxAppVersion=27.*&status=userDisabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=27.4.0&updateType=112&compatMode=normal timed out
1512691451918   addons.update-checker   WARN    Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&[email protected]&version=1.0.1b1&maxAppVersion=27.*&status=userDisabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=27.4.0&updateType=112&compatMode=normal timed out
1512691451930   addons.update-checker   WARN    Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&id={73a6fe31-595d-460b-a920-fcc0f8843232}&version=5.0.5&maxAppVersion=*&status=userDisabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=27.4.0&updateType=112&compatMode=normal timed out
1512691451935   addons.update-checker   WARN    Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&id={972ce4c6-7e08-4474-a285-3208198ce6fd}&version=27.4.0&maxAppVersion=27.4.0&status=userEnabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US&currentAppVersion=27.4.0&updateType=112&compatMode=normal timed out

[1]+  Killed                  palemoon
mr@gdOv:~$

Otherwise there have been no (other) issues, well no bad issues as for days on end earlier, no real issues whatsoever anymore now!


$ uname -a
Linux gdOv 4.9.67-unofficial+grsec171207-14 #1 SMP Thu Dec 7 15:15:37 UTC 2017 x86_64 GNU/Linux

But I think maybe I found one other reason for the (earlier) crashes.

Tor was running all the time when the crashes were happening, all these weeks. It's the Devuan/Debian Tor that runs as a "daemon", managed by (Devuan maintained) OpenRC in my boxen, and started by the init service (old sysvinit here; BTW, my system is a no-dbus system, I don't trust it, so I don't install it).

I decided it was time to try and disable Tor.

This is the state since, IIRC yesterday around yesterday morning plus minus a couple of hours (but my recollection is not always correct):


# /etc/init.d/tor status
[FAIL] tor is not running ... failed!
#

Because I had noticed earlier --only it takes time getting into my understanding properly-- these lines in my:


Dec 07 17:04:57.000 [notice] Tor 0.2.9.12 (git-2b1e823d7bc05a37) opening log file.
Dec 07 17:04:57.586 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1010006f: OpenSSL 1.1.0f  25 May 2017; running with 1010007f: OpenSSL 1.1.0g  2 Nov 2017).
Dec 07 17:04:57.612 [notice] Tor 0.2.9.12 (git-2b1e823d7bc05a37) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0g and Zlib 1.2.8.

Pls. notice "weird crashes, that might be why".

Could that have to do with these crashes in the six issues that I have reported recently? If, so more info needed.

More info needed if so, and for more I think it would be good to try and ask some Tor developers about this. And I'll try and contact some on them. Just give me a little more time.

And, if I have no more crashes, I now have nothing to reproduce... I will compile and actually try and keep regularly compiling latest vanilla kernels --is it really not the 4.9 equivalent of the grsec-unoff patched kernels that I compile, rather than the latest kernel from kernel.org like 4.14.x ?

That's it for now, waiting for more suggestions/advice/directions/clarifications/questions!

@miroR
Copy link
Author

miroR commented Dec 8, 2017

confirmation/information on tor failure with weird crashes due to "OpenSSL version from headers does not match"
https://trac.torproject.org/projects/tor/ticket/24564

Still no crashes... I think I should enable Tor, and if the crashes are back --but won't be taking to many of them to declare this issue, actually these issues, solved-- than that's it.

And if that's it, I hope Tor devs give use more clue...

@miroR
Copy link
Author

miroR commented Dec 8, 2017

This is beyond me completely.
Tor is enabled:

# /etc/init.d/tor status
[ ok ] tor is running.
#

And yet, browsing with tor-browser, and apt-get update/upgrade 'ing via tor+https went as smooth as I never expected.

And no crashes whatsoever (other than having to use safe-mode with Pale Moon, else it crashes along the lines I explained above, w/o bringing any harm to the system).

I don't know what those crashes were caused with. I will try and strain my system tonight like I made it work hard last night and with those same programs as I explained above, and... maybe we'll know more...

Regards!

@miroR miroR mentioned this issue Dec 9, 2017
Closed
@theLOICofFRANCE
Copy link

Pale-Moon seems to me less sure than Firefox. If you want a secure browser, compile firefox by disabling JIT (which will reduce javascript performance) so that it is compatible with PAX_MPROTECT.

Can we deduce from this that your problem is due to your use/environment and that it is solved?

@miroR
Copy link
Author

miroR commented Dec 15, 2017

HacKurx wrote:

Can we deduce from this that your problem is due to your use/environment and that it is solved?

If you or @minipli feel like, you can close all my reports as solved, I won't object. But, if by my problem you mean this issue #20 , the 5 months old palemoon build of mine:

# apt-cache policy palemoon
palemoon:
  Installed: 27.4.0~repack-2
  Candidate: 27.4.0~repack-2
  Version table:
 *** 27.4.0~repack-2 100
        100 /var/lib/dpkg/status
#

is not something that can be the cause of it, I think. That's homebrew Pale Moon I built, hopelessly old, for lack of time to update it. But I don't see that it crashes the system though. [1]

But don't these issues indicate the possibility of something sinister --outside of the programming errors, instead above them in a way, or on the sides such as the now somewhat known out-of-band methods that Google the world's top commercial spy agency first introduced, or the ME/PSP of Intel and AMD respectively (the latter is my system's), being it that no one else has had any of them?

I bet there are people who could tell what these crashes really are, how they were instigated, but those won't speak from their shadows. But those are my suspicions only.

Speaking of which, I think I'll update this page of mine with the few links there are currently missing there:
From SPDY to Hauppauge Card Firmware Issues. It may well be unproveable, but I do know those things that only people from that shadowy world can do --they're either too hard, or no such expensive resources are there, that just a lone hacker could do those -- [I do know those things] happened to me.

And the above I don't think is unrelated.

What I am sad about it that unsolved (well these are actually unsolved, but feel free to close them) bugs damage the perception of grsecunoff, which I continue to put my hopes in, given that spender and PaX Team left following the ripoff by Google, as spender wrote, grsecunoff.

I don't see any other complete solution for Linux security. And...

And I still think the management of these crashes in these issues #13, #17, #18, #19, #20, #21 --or in most of them-- are sooner protection by grsecunoff of my system, than grsecunoff being at fault. But it would take so much more than my insufficient knowledge to prove that...
...
[1] And to be to the point, this is current trace, as I'm posting this with my Pale Moon:
-rw-r--r-- 1 tcpdump tcpdump 9937788 2017-12-15 14:46 dump_171215_1404_gdO.pcap
It says that I've been 42 minutes online. I did start Palemoon a couple of minutes, 2-3 or so, after I connected. But it hasn't crashed this time... (However I'm online after I have Air-Gapped built my system and am useing this clone of it for online.

@minipli
Copy link
Owner

minipli commented Dec 28, 2017

The instruction pointer in the initial kernel log looks odd -- it's 0xffffc9000c6ffb80 which is 16 bytes above the current stack pointer. This would imply there was some kind of jmp *16(%rsp) instruction, which is unlikely.

Do you have CONFIG_PAX_RAP enabled? And, if so, what's the version of your gcc and binutils?
Can you provide the objdump of the failing function, likely ttm_bo_cleanup_memtype_use()?

To answer those questions you could do the following:

$ cd /path/to/your/kernel/tree/
$ grep PAX_RAP .config
$ gcc --version | head -1
$ objdump --version | head -1
$ dis-func.sh ttm_bo_cleanup_memtype_use vmlinux

The dis-func.sh script can be found here. It's just a wrapper around objdump and a perl oneliner.

@miroR
Copy link
Author

miroR commented Dec 28, 2017

$ cd /path/to/your/kernel
$ grep PAX_RAP .config

Well, the all-modules-any-system kernel that I will soon upload for anybody wishing to try and reproduce any of my issues, c'mon try somebody, I congratulate anybody who can (well maybe only the mencoder Call Trace is doable to reproduce, but it too I suspect may still have been in some of the traces I presented here triggered from the network)... [that I will soon upload] to:

https://www.croatiafidelis.hr/gnu/deb/linux-deb-grsec-current/

(I was saying) [the all-modules-any system]:


$ grep PAX_RAP /boot/config-4.9.72-unofficial+grsec171228-16 
$

had no PAX_RAP option set.

But the all-in-kernel-compiled, with only what my system needs, that of course I can't upload for others:

$ grep PAX_RAP /boot/config-4.9.70-unofficial+grsec171220-17 
CONFIG_PAX_RAP=y
CONFIG_PAX_RAP_VERBOSE=y
$

And:

$ gcc --version  | head -1
gcc (Debian 7.2.0-18) 7.2.0
$ objdump --version | head -1
GNU objdump (GNU Binutils for Debian) 2.29.1
$

but:

root@gdOv:/path/to/linux-4.9.72# dis-func.sh ttm_bo_cleanup_memtype_use vmlinux
root@gdOv:/path/to/linux-4.9.72# ls -l vmlinux
-rwxr-xr-x 1 mr mr 173913488 2017-12-28 19:19 vmlinux
root@gdOv:/path/to/linux-4.9.72#

@miroR
Copy link
Author

miroR commented Dec 29, 2017 

Dec 29 04:36:51 gdOv kernel: [253415.157880] grsec: (admin:S:/) chdir to /Cmn/src/linux-4.9.72 by /bin/bash[bash:3627] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:3626] uid/euid:0/0 gid/egid:0/0
Dec 29 04:36:53 gdOv kernel: [253417.504541] grsec: (admin:S:/) exec of /usr/local/bin/dis-func.sh (dis-func.sh ttm_bo_cleanup_memtype_use vmlinux ) by /usr/local/bin/dis-func.sh[bash:22351] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3627] uid/euid:0/0 gid/egid:0/0
Dec 29 04:36:53 gdOv kernel: [253417.507819] grsec: (admin:S:/) exec of /usr/bin/x86_64-linux-gnu-objdump (objdump -d vmlinux ) by /usr/bin/x86_64-linux-gnu-objdump[dis-func.sh:22352] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:22351] uid/euid:0/0 gid/egid:0/0
Dec 29 04:36:53 gdOv kernel: [253417.511644] grsec: (admin:S:/) exec of /usr/bin/perl (perl -e undef $/; $_=<>; /(^.*<$ENV{FUNC}>:\n(^[ \t].+\n)*)/m && print "$1" ) by /usr/bin/perl[dis-func.sh:22353] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:22351] uid/euid:0/0 gid/egid:0/0

Fri 29 Dec 06:56:07 UTC 2017

It's still at:

top - 06:54:52 up 3 days, 41 min, 18 users,  load average: 1.00, 1.01, 1.00
Tasks: 266 total,   2 running, 262 sleeping,   2 stopped,   0 zombie
%Cpu0  : 100.0/0.0   100[                                                     ]
%Cpu1  :   0.0/0.0     0[                                                     ]
%Cpu2  :   0.3/1.0     1[                                                     ]
%Cpu3  :   3.7/1.7     5[                                                     ]
KiB Mem : 12.3/16386252 [                                                     ]
KiB Swap:  0.1/8997948  [                                                     ]

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
22353 root      20   0  491156 477856   3932 R 100.0  2.9 137:33.95 perl       
30351 mr        20   0  955552 215284  44132 S   3.3  1.3   2:20.47 palemoon   
 3392 root      20   0  422452  63816   7768 S   2.6  0.4  15:04.11 Xorg       
 3651 root      20   0   25944   2512   1852 R   0.7  0.0  32:45.48 top

and the prompt is not returning:

root@gdOv:/path/to/linux-4.9.72# dis-func.sh ttm_bo_cleanup_memtype_use vmlinux

(that's the only-my-hardware-no-separate-modules kernel)

@miroR
Copy link
Author

miroR commented Dec 29, 2017 

Dec 29 08:31:02 gdOv kernel: [267466.635713] grsec: exec of /sbin/grlearn (/sbin/grlearn -stop ) by /sbin/grlearn[gradm:23292] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Dec 29 08:31:06 gdOv kernel: [267471.017523] grsec: exec of /usr/local/bin/dis-func.sh (dis-func.sh ttm_bo_cleanup_memtype_use vmlinux ) by /usr/local/bin/dis-func.sh[bash:23293] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3627] uid/euid:0/0 gid/egid:0/0
Dec 29 08:31:06 gdOv kernel: [267471.020644] grsec: exec of /usr/bin/x86_64-linux-gnu-objdump (objdump -d vmlinux ) by /usr/bin/x86_64-linux-gnu-objdump[dis-func.sh:23294] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:23293] uid/euid:0/0 gid/egid:0/0
Dec 29 08:31:06 gdOv kernel: [267471.020921] grsec: exec of /usr/bin/perl (perl -e undef $/; $_=<>; /(^.*<$ENV{FUNC}>:\n(^[ \t].+\n)*)/m && print "$1" ) by /usr/bin/perl[dis-func.sh:23295] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:23293] uid/euid:0/0 gid/egid:0/0

I waited for some 20 minutes on this one without command prompt having returned. Rebooted into vanilla kernel:

# uname -r
4.14.4171209-12
#

Now:

# ps aux | grep dis-func.sh
root      3578  0.0  0.0   4296   744 pts/13   S+   09:00   0:00 /bin/sh /usr/local/bin/dis-func.sh ttm_bo_cleanup_memtype_use vmlinux
root      3599  0.0  0.0  12804   968 pts/12   R+   09:04   0:00 grep dis-func.sh
#

Such long work this script got to do, or something wrong?

# date
Fri 29 Dec 09:10:49 UTC 2017

@minipli
Copy link
Owner

minipli commented Dec 29, 2017

Yeah, the script shouldn't take that long :/

Anyways, I assumed the panic was from a non-modular kernel, but now I'm not certain any more. You seem to change kernels frequently. Oh well, could you please try the following instead and post the output?:

objdump -wdr drivers/gpu/drm/ttm/ttm_bo.o

@miroR
Copy link
Author

miroR commented Dec 29, 2017

Yeah, the script shouldn't take that long :/

Oh, well, the verbosity or lack of it, which is better, I sometimes ask myself...

Anyways, I assumed the panic was from a non-modular kernel, but now I'm not certain any more. You seem to change kernels frequently.

No, I don't. I use only two sets of kernels, one is no-modules-loading my own hardware only, for my regular use, and the other is what I offer to others, which has all the modules as any general-purpose kernel, compiled separately, and I offer them at https://www.croatiafidelis.hr/gnu/deb/linux-deb-grsec-current/ and have dedicated topics at:
https://dev1galaxy.org/viewtopic.php?id=596
and
http://forums.debian.net/viewtopic.php?f=16&t=108616
along with script https://github.com/miroR/grsec-dev1-compile for newbies how to compile such kernels themselves, but surely for complete newbies only the packages are feasible to install, so I offer those in the link further above in this post...
Both those sets are only sets because the version changes 4.9.72 being current --yet to upload, but already being tested as I write--, and all are based on @minipli's kernel, because you're some of us' last hope. Us who don't trust vanilla, not to say more...

Oh well, could you please try the following instead and post the output?:

objdump -wdr drivers/gpu/drm/ttm/ttm_bo.o

Sure!

@miroR
Copy link
Author

miroR commented Dec 29, 2017 •
edited
Loading

Wow! That's 360k ... I think I'd better upload it. Temporarily (but no rush to remove it), but that takes me longer than posting here, because I'll upload the:

$ uname -r
4.9.72-unofficial+grsec171228-16
$

that I compiled yesterday, in the same session, [temporarily] I'll post it in:
where I upload the deb packages, it will keep the name:

$ ls -ABRgo /Cmn/mr/objdump-wdr_171229_103951_drivers_gpu_drm_ttm_ttm_bo_o 
-rw-r--r-- 1 367786 2017-12-29 10:37 /Cmn/mr/objdump-wdr_171229_103951_drivers_gpu_drm_ttm_ttm_bo_o

Give me a little time now to do it... (and I hope crashes won't make it longer and worse...)

@miroR
Copy link
Author

miroR commented Dec 29, 2017

It's there, along with it's sig:
https://www.croatiafidelis.hr/gnu/deb/objdump-wdr_171229_103951_drivers_gpu_drm_ttm_ttm_bo_o
https://www.croatiafidelis.hr/gnu/deb/objdump-wdr_171229_103951_drivers_gpu_drm_ttm_ttm_bo_o.sig

@minipli
Copy link
Owner

minipli commented Dec 29, 2017

The objdump looks good. However, I probably need the following files, too -- depending on which one you're using:

  • drivers/gpu/drm/amd/amdgpu/amdgpu.o and/or
  • drivers/gpu/drm/nouveau/nouveau.o

Have you been able to reproduce the panic with .72?

@miroR
Copy link
Author

miroR commented Dec 29, 2017

The objdump looks good. However, I probably need the following files, too -- depending on which one you're using:

drivers/gpu/drm/amd/amdgpu/amdgpu.o and/or
drivers/gpu/drm/nouveau/nouveau.o

Will do it. A little time I need.

Have you been able to reproduce the panic with .72?

Hey, it's not in the world typical, what happens here, for programming errors, such as would be the case if your patch contained programming errors. It just wouldn't be this erratic, or at least it is not typical for programs with errors to so often and so much be so very erratic...

Namely I occasionally have no Call Traces whatsoever for even approx. 4-5 days (didn't count), and then I can't stop having them... But that was earlier, as I posted about it (or gave links, in the verbose reports of mine in the past weeks). It hasn't repeated such absolutely worse kind of condition lately... I'm not saying it won't, but that it, likely, depends on the attacker, in my theory at least.

I have had one rsyslog-recorded trace with 4.9.70 on Dec 27, and two or three not-recorded in the syslog on Dec 29, but none so far with 4.9.72 all-modules-any-system that I uploaded for the world, nor with 4.9.72 no-modules-loading only-my-hardware that I'm running now.

I can post the 4.9.70 trace and explain when at least one of the not recorded crashes happened, but in a few hours. And I'll take care to post it in the proper old or new that it should be, issue, as best I will know.

@miroR
Copy link
Author

miroR commented Dec 29, 2017 •
edited
Loading

The objdump looks good. However, I probably need the following files, too [...cut...]:
drivers/gpu/drm/amd/amdgpu/amdgpu.o

Uploaded:
https://www.croatiafidelis.hr/gnu/deb/objdump-wdr_171229_200531_drivers_gpu_amd_amdgpu_amdgpu_o.gz
https://www.croatiafidelis.hr/gnu/deb/objdump-wdr_171229_200531_drivers_gpu_amd_amdgpu_amdgpu_o.sig

@miroR miroR mentioned this issue Feb 16, 2018
Open
@miroR miroR mentioned this issue Jun 8, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@theLOICofFRANCE @minipli @miroR