Bug#1009359: New security upgrade prevent Chromium from starting

2022-04-18 Thread Andres Salomon 
Hm, good question. What I'd start doing is looking at the 
~/.cache/chromium and ~/.config/chromium snapshots, making copies, and 
then trying to run chromium with random stuff deleted.



For example, on my system I have ~/.cache/chromium/Profile 
1/old_Cache_000 and ~/.cache/chromium/System Profile/Code Cache and 
~/.cache/chromium/Profile 1/Cache/Cache_Data/. So I'd start by deleting 
old_Cache_000 and seeing if it still crashes. If it does, I'd get rid of 
the Code Cache as well. If it doesn't still crash, I'd copy Code Cache 
back over and then try deleting Cache_Data. If that directory is needed 
to get it to crash, I'd try deleting files within that directory until I 
had a minimal number of files that still cause the crash. I'd do the 
same for my ~/.config/chromium directory, too.


Once you have a minimal snapshot, you can look at the individual items 
in the snapshot to see if any sensitive work info is in there. If it's 
just, say, internal gitlab urls and pages that don't have proprietary 
details of your workplace, then maybe you could file a bug and include a 
tarball with those. If it does include sensitive data, then either it's 
time to give up or you could try editing the cache/config files to try 
and replace the details in the file. Eg, if the cache has the code name 
of some unreleased product, you might be able to just change the string 
from "Seckrit name" to "foobar1 name" and see if it still crashes.


I don't know how chromium will behave with only half a cache, but it 
would be good to do a sanity check every once in a while by (again, 
after making a backup copy) starting chromium with -g to ensure it 
repairs itself and runs like with your full cache snapshot.



On 4/18/22 03:49, Anthony Callegaro wrote:

Hey Andres,

I do have a copy of the crashing Chromium profile but this is my professional 
one. And though I would love to help discovering a security bug in Chromium, I 
work in a security sensitive environment and wouldn't be able to share it 
without finding a way of selectively removing things from cache.

Do you know if that's even possible ?

Take care
LeTic

Bug#1009359: New security upgrade prevent Chromium from starting

2022-04-13 Thread Andres Salomon 

On 4/13/22 12:11, Anthony Callegaro wrote:

Me again,

I tried debugging further. If I remove the Preferences file I am then able to 
start chromium and if I try to restore pages from the window that makes it 
crashes manually I manage to restore some tabs but some will make it crash 
consistently.

The weird thing is that I have several tabs from the same domain (i.e. our 
internal gitlab) and some will make chromium crash while other from the same 
domain won't.

I do manage to open these tabs from a clean session without crashes.



That's bizarre.  So just to be clear, if you start chromium 
--temp-profile and go to the internal gitlab page(s), it's fine every 
time. However, if you mkdir /tmp/myhome; chromium 
--user-data-dir=/tmp/myhome; and then configure settings (in 
chrome://settings/onStartup) to continue where you left off, go to the 
internal gitlab page(s), close the browser and restart it again with 
chromium --user-data-dir=/tmp/myhome, it crashes? Or does it only crash 
with your specific older cache?


And chromium's crashpad handler isn't giving you any kind of backtrace?  
What about if you run chromium -g?






So I thought that maybe the cache was corrupted and tried running with the 
following, and got a new error :


chromium --aggressive-cache-discard
[134834:134834:0413/180206.632615:ERROR:sandbox_linux.cc(377)] 
InitializeSandbox() called with multiple threads in process gpu-process.
*** stack smashing detected ***: terminated
[134835:134847:0413/180211.873710:ERROR:ssl_client_socket_impl.cc(997)] 
handshake failed; returned -1, SSL error code 1, net_error -3
Trace/breakpoint trap1

Would a full strace help ? Here is the tail :


clock_gettime(CLOCK_MONOTONIC, {tv_sec=46426, tv_nsec=739454484}) = 0
write(30, "\0", 1)  = 1
getrandom("\x1e\x85\x40\xd1\xe5\x34\xa6\x14\xbb\x67\xaa\xae\xc9\xe0\x70\x72", 
16, 0) = 16
getrandom("\xa1\x79\xcb\x8d\xd1\x7e\x75\xd5\xdc\x71\x7a\x42\x6c\x49\x99\x02", 
16, 0) = 16
getrandom("\x27\xb6\x64\xa2\x8d\x24\x75\xc2\x04\xb9\x93\x10\xad\x0b\x1f\xce", 
16, 0) = 16
getrandom("\xaa\x09\xc9\x17\x34\xd6\xea\xcf\x3a\x3c\x7c\xd5\x02\xeb\xd1\x19", 
16, 0) = 16
getrandom("\x69\x79\x27\x44\x05\x46\x2a\x0c\x81\xa1\xbc\xea\xe2\x99\x3e\xcc", 
16, 0) = 16
getrandom("\x93\x05\xa1\xa1\xda\x79\xb4\xfd\x46\xf8\x61\x48\x98\x96\x6b\x12", 
16, 0) = 16
getrandom("\x90\x1b\xdf\xfd\xc4\x03\x92\xca\xdf\x74\x85\x90\x21\x78\x9f\x83", 
16, 0) = 16
clock_gettime(CLOCK_MONOTONIC, {tv_sec=46426, tv_nsec=740413539}) = 0
futex(0x7f61777fd528, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x7f61777fd4d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55f686cb5ca8, FUTEX_WAKE_PRIVATE, 1) = 1
clock_gettime(CLOCK_MONOTONIC, {tv_sec=46426, tv_nsec=740599805}) = 0
futex(0x7f61777fd528, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x7f61777fd4d8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55f686cb5ca8, FUTEX_WAKE_PRIVATE, 1) = 1
getrandom("\x00\xac\x62\x93\xd0\x11\x62\xa7\xfe\x7f\xc6\x2b\x7a\xe4\xa0\xf5", 
16, 0) = 16
gettimeofday({tv_sec=1649866186, tv_usec=877238}, {tz_minuteswest=-120, 
tz_dsttime=0}) = 0
brk(0x55f687f25000) = 0x55f687f25000
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
gettid()= 136609
prctl(PR_GET_DUMPABLE)  = 1 (SUID_DUMP_USER)
rt_sigprocmask(SIG_BLOCK, [CONT], [TRAP], 8) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\0\0\0\1\0\0\0\250\271\353\214a\177\0\0H\361\307\206\366U\0\0\0\0\0\0\0\0\0\0"...,
 iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 40
rt_sigtimedwait([CONT], [0413/180946.877861:ERROR:scoped_ptrace_attach.cc(27)] 
ptrace: Operation not permitted (1)
{si_signo=SIGCONT, si_code=SI_TKILL, si_pid=136623, si_uid=1000}, {tv_sec=5, 
tv_nsec=0}, 8) = 18 (SIGCONT)
rt_sigprocmask(SIG_SETMASK, [TRAP], NULL, 8) = 0
futex(0x55f686c7f168, FUTEX_WAKE_PRIVATE, 2147483647) = 0
rt_sigaction(SIGTRAP, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, 
sa_restorer=0x7f618ce83140}, NULL, 8) = 0
getpid()= 136609
gettid()= 136609
rt_tgsigqueueinfo(136609, 136609, SIGTRAP, {si_signo=SIGTRAP, 
si_code=SI_KERNEL}) = 0
rt_sigreturn({mask=[]}) = 24
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
[136654:136660:0413/180946.892051:ERROR:ssl_client_socket_impl.cc(997)] 
handshake failed; returned -1, SSL error code 1, net_error -3
+++ killed by SIGTRAP +++
Trace/breakpoint trap

Thanks in advance for any insight
LeTic

--- Original Message ---
On Wednesday, April 13th, 2022 at 11:56, Anthony Callegaro 
 wrote:





Hey Andres,

Thanks for taking a look. Here are the info :

libdrm-amdgpu1:amd64/bullseye 2.4.104-1 uptodate
libdrm-intel1:amd64/bullseye 2.4.104-1 uptodate
libdrm-nouveau2:amd64/bullseye 2.4.104-1 uptodate
libdrm-radeon1:amd64/bullseye 2.4.104-1 uptodate
libdrm2:amd64/bullseye 2.4.104-1 uptodate
libgl1:amd64/bullseye 1.3.2-1 uptodate
libgl1-mesa-dri:amd64/bul

Bug#1009359: New security upgrade prevent Chromium from starting

2022-04-12 Thread Andres Salomon 



On 4/12/22 08:02, Anthony Callegaro wrote:

Hi guys,

I tried a few additional things to try to sort it out :
-   downgraded to my latest upgrade date :
cat /etc/apt/sources.list.d/snapshot.list
deb [check-valid-until=no] 
http://snapshot.debian.org/archive/debian-security/20220404T151623Z/ 
stable-security main contrib non-free
cat /etc/apt/preferences.d/snapshot.pref
Package: *
Pin: origin snapshot.debian.org
Pin-Priority: 1001
apt update
apt upgrade
- Also downgraded the flatpak dependencies (as there was some mesa.GL upgrade)

So I guess that during the first Chromium run it changed a default parameter in 
my profile (enabling some hardware accelaration or so) which broke it. So I 
will try to reset my profile and keep you updated.

Cheers




Speaking of mesa.GL, it occurs to me that libgles2 and other GL 
libraries should really be in your depends/recommends/suggests lists, 
but they're not (probably because they're detected and dlopened at 
runtime, similar to the problem we had in #1005230). What version of the 
following packages do you have installed?


libgles2 libgl1-mesa-dri libllvm11 libdrm-amdgpu1 libdrm-intel1 
libdrm-nouveau2 libdrm-radeon1 libdrm2 libva-drm2 libva-x11-2 
libigdgmm11 libvulkan1 libglapi-mesa libglx-mesa0 libglx0 libgl1 libglvnd0



We don't have swiftshader enabled in debian chromium packages, so if 
there's something wrong with your hardware acceleration stuff, we don't 
have a good fallback.