In Gentoo Hardened, mosh-server segfaults. The plt code for forkpty winds up jmping to zero. Is this a glibc issue? A linking issue with mosh? Should be pretty easy to reproduce. Emerge mosh, run mosh-server, look in dmesg.
What's your exact hardened setup? Which version of mosh do you use? It works on my hardened machine % emerge -pv mosh These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R *] net-misc/mosh-9999::gentoo USE="client mosh-hardening server utempter -examples -ufw" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB % emerge --info Portage 2.2.26 (python 2.7.10-final-0, hardened/linux/amd64/no-multilib, gcc-4.9.3, glibc-2.21-r2, 4.3.5-hardened-r2-lore.0 x86_64) ================================================================= System uname: Linux-4.3.5-hardened-r2-lore.0-x86_64-Intel-R-_Core-TM-_i7-2600_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 32812124 total, 1548296 free KiB Swap: 33554428 total, 33276044 free Timestamp of repository gentoo: Wed, 24 Feb 2016 01:00:01 +0000 sh bash 4.3_p42-r1 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 distcc 3.2rc1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.3_p42-r1::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10-r1::gentoo, 3.4.3-r1::gentoo dev-util/cmake: 3.3.1-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.19.1::gentoo sys-apps/sandbox: 2.10-r1::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 xmw location: /var/lib/layman/xmw masters: gentoo priority: 0 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind /var/spool/munin-async/.ssh" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/var/cache/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/var/cache/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="acl amd64 apache2 bash-completion bazaar berkdb bzip2 cli cracklib crypt cxx dovecot-sasl dri gdbm git hardened iconv ipv6 justify mmx mmxext modules ncurses nls nptl openmp pam pax_kernel pcre perl pie png python readline seccomp session sse sse2 ssl ssp subversion tcpd threads unicode urandom vhosts vim-syntax xattr xtpax zlib zsh-completion" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias proxy proxy_http" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US de de_DE" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64 arm" QEMU_USER_TARGETS="x86_64 arm armeb" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Portage 2.2.27 (python 3.4.3-final-0, unavailable, gcc-5.3.0, glibc-2.22-r2, 3.14.60-grsec x86_64) monder ~ # emerge -pv mosh These are the packages that would be merged, in order: Calculating dependencies... done! [binary R ] net-misc/mosh-1.2.5-r1::gentoo USE="client mosh-hardening server utempter -examples -ufw" 293 KiB Total: 1 package (1 reinstall, 1 binary), Size of downloads: 293 KiB
So I'm on gcc 5.3 and glibc 2.22, and you're not, it appears. Also I'm using the stable grsec instead of the testing grsec, but that might not be the issue.
I am on gcc 4.9.3 and ran into this issue after upgrading glibc from 2.21-r2 to 2.22-r4. It appears the issue[1] is already resolved upstream[2]. There are no segfaults when using the 9999 ebuild, and they are resolved when backporting the patch from [2] into the 1.2.5-r1 ebuild. [1] https://github.com/mobile-shell/mosh/issues/727 [2] https://github.com/mobile-shell/mosh/pull/733
(In reply to Jack Suter from comment #4) > I am on gcc 4.9.3 and ran into this issue after upgrading glibc from 2.21-r2 > to 2.22-r4. It appears the issue[1] is already resolved upstream[2]. > > There are no segfaults when using the 9999 ebuild, and they are resolved > when backporting the patch from [2] into the 1.2.5-r1 ebuild. > > [1] https://github.com/mobile-shell/mosh/issues/727 > [2] https://github.com/mobile-shell/mosh/pull/733 This is not a hardened issue, its in glibc. Also, mosh's pr might work around the segfault, but its not a fix. Something changed in glibc's linking, probably in ld.so. s/-pthreads -lpthreads/-pthreads/ is correct, but adding -lpthreads shouldn't lead to a segfault. Here's some reduced code: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817929#35 @vapier. are you familiar?
the issue has been reported upstream and being discussed there: https://sourceware.org/bugzilla/show_bug.cgi?id=19861 https://sourceware.org/ml/libc-alpha/2016-03/msg00725.html
*** Bug 579584 has been marked as a duplicate of this bug. ***
*** Bug 579804 has been marked as a duplicate of this bug. ***
According to the mosh issue 727 it's a protobuf problem: https://github.com/google/protobuf/pull/1333
(In reply to Dennis Lichtenthäler from comment #9) > According to the mosh issue 727 it's a protobuf problem: > https://github.com/google/protobuf/pull/1333 This looks like a proposed workaround, rather than related to the actual problem. Note Konsole (see bug 579804) does not use protobuf.
(In reply to Dennis Lichtenthäler from comment #9) it's a bug in glibc. see the referenced upstream bug.
Is this a bug related to =glibc-2.22 or >=glibc-2.22 ? I'm asking because I have masked =glibc-2.22 on my system but now also latest openoffice-bin ask that version as minimum requirement
I just wanted to check what the suggested way to go here is. Do we want to include the upstream patch to mosh that makes it work with the current stable glibc version, or do we wait until the bug is resolved in glibc and a fixed glibc version becomes stable?
this bug will be closed when we get the fix into glibc. whether other pkg maintainers want to mitigate it in the meantime is up to them.
(In reply to SpanKY from comment #14) > this bug will be closed when we get the fix into glibc. whether other pkg > maintainers want to mitigate it in the meantime is up to them. It seems that upstream has fixed the bug, is it possible to insert the upstream fix in the current stable glibc release?
Created attachment 439514 [details] Ebuild that uses upstream patch The attached ebuild uses the upstream patch from mosh
Created attachment 439516 [details, diff] Upstream patch to mosh The mosh upstream source code patch that fixes the problem: https://github.com/mobile-shell/mosh/pull/733/files
(In reply to Fabio Rossi from comment #15) > It seems that upstream has fixed the bug, is it possible to insert the > upstream fix in the current stable glibc release? It does seem possible. I tested patching the upstream glibc fix into sys-libs/glibc-2.23-r2 (see bug 584916 comment #12) and it made the segfault go away for me.
*** Bug 584916 has been marked as a duplicate of this bug. ***
Hi. Is there any status for glibc fixing? A lot of time have passed already.
*** Bug 597986 has been marked as a duplicate of this bug. ***
Indeed, and the affected glibcs are now in stage3s, making it slightly difficult to go back to a working version. :/
should be fixed with >=glibc-2.23-r3
(In reply to SpanKY from comment #23) > should be fixed with >=glibc-2.23-r3 Even though upstream's https://sourceware.org/bugzilla/show_bug.cgi?id=20188 is still unresolved?
(In reply to Luke-Jr from comment #24) if you read the summary, that is about vfork wrappers. this bug is about forkpty which uses fork which is fixed (as is referenced in the upstream bug reports).
Ah, didn't realise this bug was just the fork side. Should I open another one for vfork, or is there already such a tracker?
(In reply to Luke-Jr from comment #26) if you don't have a known breaking package, then there's no point in filing a bug on our side. it's not like we're going to do anything ahead of upstream glibc.
