Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2019-12-25 11:28:20, Jeremie Courreges-Anglas  wrote:
> On Tue, Dec 24 2019, Bryan Linton  wrote:
> > On 2019-12-22 09:05:42, Frederic Cambus  wrote:
> >> CVSROOT:   /cvs
> >> Module name:   ports
> >> Changes by:fcam...@cvs.openbsd.org 2019/12/22 09:05:42
> >> 
> >> Modified files:
> >>productivity/ledger: Makefile distinfo 
> >>productivity/ledger/patches: patch-src_CMakeLists_txt 
> >>productivity/ledger/pkg: PLIST 
> >> Removed files:
> >>productivity/ledger/patches: patch-src_item_h 
> >> 
> >> Log message:
> >> Update ledger to 3.1.3.
> >> 
> >> This fixes CVE-2017-2807, CVE-2017-2808, CVE-2017-12481, CVE-2017-12482.
> >> 
> >> OK jca@, Sergey Bronnikov (MAINTAINER)
> >> 
> >
> > This update causes ledger to segfault when processing commodities.
> >
> > I can reproduce this with a file consisting of the following
> > snippet from ledger's manual.
> >
> > -8<--
> >
> > 9/29  Get some stuff at the Inn
> > Places:Black's Tavern   -3 Apples
> > Places:Black's Tavern   -5 Steaks
> > EverQuest:Inventory
> >
> > -8<--
> >
> > To reproduce, simply copy the above 4 lines to a file and run
> > ledger.  E.g. "ledger --file test.txt balance"
> >
> > If I remove the commodities from my (much longer) journal, ledger
> > works fine when dealing with cash transactions so the bug must be
> > specific to commodities.
> >
> > Can anyone else reproduce this?
> 
> Using your testcase, nope:
> 
> --8<--
> ritchie ~/tmp$ ledger -f testcase  balance; echo "status: $?"; ledger 
> --version | head -n1
> 3 Apples
> 5 Steaks  EverQuest:Inventory
>-3 Apples
>-5 Steaks  Places:Black's Tavern
> 
>0
> status: 0
> Ledger 3.1.3-20190331, the command-line accounting tool
> -->8--
> 

It must have been a hiccup with my system then.

I updated packages again, removed old .libs-* packages, and
rebuilt ledger and now I can no longer reproduce it either.

Apologies for the false alarm.  And many thanks to the maintainers
of ledger for keeping it up to date!

-- 
Bryan

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2019-12-22 09:05:42, Frederic Cambus  wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   fcam...@cvs.openbsd.org 2019/12/22 09:05:42
> 
> Modified files:
>   productivity/ledger: Makefile distinfo 
>   productivity/ledger/patches: patch-src_CMakeLists_txt 
>   productivity/ledger/pkg: PLIST 
> Removed files:
>   productivity/ledger/patches: patch-src_item_h 
> 
> Log message:
> Update ledger to 3.1.3.
> 
> This fixes CVE-2017-2807, CVE-2017-2808, CVE-2017-12481, CVE-2017-12482.
> 
> OK jca@, Sergey Bronnikov (MAINTAINER)
> 

This update causes ledger to segfault when processing commodities.

I can reproduce this with a file consisting of the following
snippet from ledger's manual.

-8<--

9/29  Get some stuff at the Inn
Places:Black's Tavern   -3 Apples
Places:Black's Tavern   -5 Steaks
EverQuest:Inventory

-8<--

To reproduce, simply copy the above 4 lines to a file and run
ledger.  E.g. "ledger --file test.txt balance"

If I remove the commodities from my (much longer) journal, ledger
works fine when dealing with cash transactions so the bug must be
specific to commodities.

Can anyone else reproduce this?

Unfortunately, I don't see any commits in ledger's GitHub that
stand out as fixing this issue.  I do see several commits to
commodity handling in between the previous 3.1.1 release and the
current 3.1.3 release.  However, I don't currently have time to
attempt to bisect this.

Backtrace follows.

% sysctl kern.version
kern.version=OpenBSD 6.6-current (GENERIC.MP) #559: Sun Dec 22 23:03:43 MST 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

% ledger bal
zsh: segmentation fault (core dumped)  ledger bal

% egdb `which ledger` ledger.core
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/ledger...done.
[New process 605898]
Core was generated by `ledger'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00dbd4413389 in 
std::__1::__hash_table, std::__1::__unordered_map_hasher, 
std::__1::hash, true>, 
std::__1::__unordered_map_equal, 
std::__1::equal_to, true>, 
std::__1::allocator > >::__deallocate_node (this=0xddd5619520, __np=0x2)
at /usr/include/c++/v1/__hash_table:1584
1584__next_pointer __next = __np->__next_;
(gdb) bt
#0  0x00dbd4413389 in 
std::__1::__hash_table, std::__1::__unordered_map_hasher, 
std::__1::hash, true>, 
std::__1::__unordered_map_equal, 
std::__1::equal_to, true>, 
std::__1::allocator > >::__deallocate_node (this=0xddd5619520, __np=0x2)
at /usr/include/c++/v1/__hash_table:1584
#1  0x00dbd441332c in 
std::__1::__hash_table, std::__1::__unordered_map_hasher, 
std::__1::hash, true>, 
std::__1::__unordered_map_equal, 
std::__1::equal_to, true>, 
std::__1::allocator > >::~__hash_table (this=0xddd5619520)
at /usr/include/c++/v1/__hash_table:1540
#2  0x00dbd44132cf in std::__1::unordered_map, 
std::__1::equal_to, 
std::__1::allocator > >::~unordered_map (this=0xddd5619520)
at /usr/include/c++/v1/unordered_map:842
#3  0x00dbd441328f in ledger::balance_t::~balance_t (this=0xddd5619520)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/balance.h:140
#4  0x00dbd4413144 in boost::checked_delete 
(x=0xddd5619520)
at /usr/local/include/boost/core/checked_delete.hpp:34
#5  0x00dbd44130b2 in ledger::value_t::storage_t::destroy 
(this=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:219
#6  0x00dbd4412ff6 in ledger::value_t::storage_t::~storage_t 
(this=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:172
#7  0x00dbd4412fa4 in boost::checked_delete (x=0xde5ab16300)
at /usr/local/include/boost/core/checked_delete.hpp:34
#8  0x00dbd4412f4c in ledger::value_t::storage_t::release 
(this=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:203
#9  0x00dbd4412eef in ledger::intrusive_ptr_release 
(storage_ptr=0xde5ab16300)
at /usr/obj/ports/ledger-3.1.3/ledger-3.1.3/src/value.h:210
#10 0x00dbd4404977 in 
boost::intrusive_ptr::~intrusive_ptr (
this=0x7f7dc510) at 
/usr/local/include/boost/smart_ptr/intrusive_ptr.hpp:98
#11 0x00de062bcf76 in ledger::xact_base_t::finalize() () 

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2018-05-13 12:01:52, Landry Breuil  wrote:
> 
> Sadly, this trace doesnt really help, since it seems to be a signal
> handler that catches the SIGABRT, or the signal handler is in the main
> process and the abort is in the content process, and not the trace of
> the codepath that triggers this SIGABRT...
> 
> How about trying it live (if you can) within egdb following all
> processes, with a breakpoint on signal or SYS_access ?
> 

Hello,

I tried to run firefox in egdb but I'm having some difficulty.
egdb seems to crash and then takes my entire system down with it.
Mouse, keyboard, CTRL+ALT+DEL, CTRL+ALT+BKSP, all stop working.

I saw your recent mail to ports@ about how to help debug the new
pledged firefox, and what other info may help too (ktrace etc.).

I'll try to see if I can figure out why egdb is crashing and
provide some more information soon, but I may not be able to do so
until this weekend.  (The first thing I'll try is updating to a
newer snapshot.)

Until then, please don't let this bug report hold you back from
doing any work you had planned.  For the meantime at least,
firefox runs fine with the getpw pledge added.  That and the fact
that I seem to be the only one experiencing this crash tells me
that this bug is probably only affecting me at the moment.

Anyway, thanks again for all the work you've put in to pledging
firefox!

-- 
Bryan

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2018-05-12 20:02:40, Landry Breuil <lan...@openbsd.org> wrote:
> On Sat, May 12, 2018 at 08:07:17PM +0900, Bryan Linton wrote:
> > 
> > Adding the "getpw" pledge to "security.sandbox.pledge.content"
> > doesn't fix it.  However adding it to "security.sandbox.pledge.main"
> > lets everything run just fine again.
> 
> Well, i can't reproduce it here, and i have no issue calling 'save link
> as' or 'save page as' dialogs without getpw pledge on main process.
> Though i havent tried *actually* saving the image/page.
> 
> I'll need a bit more context.. can you look at the coredump with egdb
> from ports and try to get the backtrace for the pledge abort, so that we
> figure out if it's within firefox or the glib layers ?
>

% dmesg | grep GENERIC | tail -2
OpenBSD 6.3-current (GENERIC.MP) #14: Thu Apr 26 21:03:52 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

% ls -la /etc/malloc.conf
ls: /etc/malloc.conf: No such file or directory

% firefox -profilemanager
[create new, blank profile with no add-ons or extensions installed]

[firefox gets killed by pledge() upon "Right-click -> Save link as..."]
firefox[99269]: pledge "getpw", syscall 33

% egdb `which firefox` firefox.core 
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/firefox...done.
[New process 127256]
[New process 197917]
[New process 278895]
[New process 359186]
[New process 490001]
[New process 121875]
[New process 569901]
[New process 262854]
[New process 185179]
[New process 532300]
[New process 186272]
[New process 495833]
[New process 422756]
[New process 195461]
[New process 114351]
[New process 372828]
[New process 596628]
[New process 415519]
[New process 596946]
[New process 181949]
[New process 235073]
Core was generated by `firefox'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x in ?? ()
[Current thread is 1 (process 127256)]
(gdb) bt
#0  0x in ?? ()
#1  0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2  
#3  0x in ?? ()
#4  0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#5  
#6  0x in ?? ()
#7  0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#8  
#9  0x in ?? ()
#10 0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0

[...many identical lines deleted]

#2323 0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2324 
#2325 0x in ?? ()
#2326 0x0fea5628401f in WasmFaultHandler(int, siginfo_t*, void*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2327 
#2328 0x0fea53142659 in 
mozilla::ipc::MessageChannel::OnChannelErrorFromLink() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2329 0x0fea53143c31 in non-virtual thunk to 
mozilla::ipc::ProcessLink::OnChannelError() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2330 0x0fea53127a2e in event_persist_closure ()
at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1580
#2331 event_process_active_single_queue ()
at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1639
#2332 0x0fea531251fe in event_process_active ()
at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1741
#2333 event_base_loop () at 
/usr/obj/ports/firefox-60.0-debug/firefox-60.0/ipc/chromium/src/third_party/libevent/event.c:1961
#2334 0x0fea531129c5 in 
base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () from 
/usr/local/lib/firefox/libxul.so.77.0
#2335 0x0fea53111417 in MessageLoop::Run() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2336 0x0fea5311bf35 in base::Thread::ThreadMain() () from 
/usr/local/lib/firefox/libxul.so.77.0
#2337 0x0fea53116f0a in ThreadFunc(void*) () from 
/usr/local/

Re: CVS: cvs.openbsd.org: ports

[Bryan Linton]

On 2018-05-11 14:00:57, Landry Breuil  wrote:
> CVSROOT:  /cvs
> Module name:  ports
> Changes by:   lan...@cvs.openbsd.org  2018/05/11 14:00:57
> 
> [...]
> 
> Log message:
> Update to firefox 60.
>
> [...]
>
> If you encounter crashes due to pledge, look into your kernel log, and
> try to figure out what missing pledge is needed or what firefox codepath
> hits it.
> 
> [...]
>
> So far i know 'getpw' might be needed when uploading files but i havent
> hit it, and 'proc' might be needed by the content process when there's
> no dbus daemon running, but they're not needed in the 'common case', and
> too broad.
> 

Hello,

I've found that a simple "Right-click -> Save image as" or
"Right-click -> Save link as" causes Firefox to crash.

firefox[77259]: pledge "getpw", syscall 33
firefox[11365]: pledge "getpw", syscall 33
firefox[11365]: pledge "stdio", syscall 29
firefox[76277]: pledge "getpw", syscall 33
firefox[10702]: pledge "getpw", syscall 33

I tried four separate times.  All of them showed a "getpw" pledge
error.  For some reason, one of the trials also caused it to emit
an "stdio" pledge error too.

I see that stdio is already pledged, so I have no idea why or
where that error came from.

FWIW, /usr/src/sys/kern/syscalls.master says that syscalls 29 and 33 are
the following:

29  STD { ssize_t sys_recvfrom(int s, void *buf, size_t len, \
int flags, struct sockaddr *from, \
socklen_t *fromlenaddr); }

33  STD { int sys_access(const char *path, int amode); }

Adding the "getpw" pledge to "security.sandbox.pledge.content"
doesn't fix it.  However adding it to "security.sandbox.pledge.main"
lets everything run just fine again.


I'd also like to take this opportunity to thank you (and all the
others!) who put in all the effort to pledge Firefox.  Thank you! 

-- 
Bryan