<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>bug on head /dev/log</title>
    <link>https://www.lamy.im/tags/bug/</link>
    <description>Recent content in bug on head /dev/log</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 10 Mar 2019 21:21:07 +0000</lastBuildDate><atom:link href="https://www.lamy.im/tags/bug/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>gcc compilation  failure (Value too large for defined data type)</title>
      <link>https://www.lamy.im/posts/gcc-compilation-failure-value-too-large-for-defined-data-type/</link>
      <pubDate>Sun, 10 Mar 2019 21:21:07 +0000</pubDate>
      
      <guid>https://www.lamy.im/posts/gcc-compilation-failure-value-too-large-for-defined-data-type/</guid>
      <description>I just reinstalled some of my servers with my beloved combo : gentoo &amp;amp; XFS &amp;lt;3
When I was trying to upgrade my gcc version from 7.3 to 8.2 I got the following error :
&amp;lt;pre class=&amp;#34;wp-block-code&amp;#34;&amp;gt;``` checking for uintptr_t... * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/libsandbox.c:check_syscall():968: failure (Value too large for defined data type): * ISE: fopen_wr(conftest.val) abs_path: (null) res_path: /var/tmp/portage/sys-devel/gcc-8.2.0-r6/work/build/x86_64-pc-linux-gnu/32/libatomic/conftest.val configure: error: Could not determine word size. I finally found in that very old gentoo forum post and bug report that XFS is the rootcause.</description>
      <content>&lt;p&gt;I just reinstalled some of my servers with my beloved combo : gentoo &amp;amp; XFS &amp;lt;3&lt;/p&gt;
&lt;p&gt;When I was trying to upgrade my gcc version from 7.3 to 8.2 I got the following error :&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&amp;lt;pre class=&amp;#34;wp-block-code&amp;#34;&amp;gt;```
checking for uintptr_t...  * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/libsandbox.c:check_syscall():968: failure (Value too large for defined data type):
 * ISE: fopen_wr(conftest.val)
        abs_path: (null)
        res_path: /var/tmp/portage/sys-devel/gcc-8.2.0-r6/work/build/x86_64-pc-linux-gnu/32/libatomic/conftest.val
configure: error: Could not determine word size.
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;I finally found in that very old &lt;a href=&#34;https://forums.gentoo.org/viewtopic-p-7440348.html&#34;&gt;gentoo forum post&lt;/a&gt; and &lt;a href=&#34;https://bugs.gentoo.org/471024&#34;&gt;bug report&lt;/a&gt; that XFS is the rootcause. So I decided to move my ‘/var/tmp/portage’ from XFS to tmpfs by adding the following to /etc/fstab. Size may be adapted but 2G is not enough to compile GCC successfully.&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;&amp;lt;pre class=&amp;#34;wp-block-preformatted&amp;#34;&amp;gt;tmpfs /var/tmp/portage tmpfs size=4G,uid=portage,gid=portage,mode=775,noatime        0 0
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Then I resumed the compilation, it worked like a charm and I was able to set my new GCC version as default one.&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ emerge --resume
$ gcc-config -l
[1] x86_64-pc-linux-gnu-7.3.0 *
[2] x86_64-pc-linux-gnu-8.2.0 
$ gcc-config 2
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Again, gentoo documentation and resources was awesome 🙂&lt;/p&gt;
</content>
    </item>
    
    <item>
      <title>systemd-journald exploit &amp; root access</title>
      <link>https://www.lamy.im/posts/systemd-journald-exploit-root-access/</link>
      <pubDate>Thu, 10 Jan 2019 21:47:24 +0000</pubDate>
      
      <guid>https://www.lamy.im/posts/systemd-journald-exploit-root-access/</guid>
      <description>Des chercheurs de Qualys ont découvert 3 failles de sécurité dans journald qui permet une escalade de privilège. Des PoC ont été fait et cela prend 10minutes sur i386 et 70minutes sur amd64. Attention donc, car tous les patchs ne sont pas encore dispo.
Ci dessous le résumé provenant de chez qualys:
========= Summary =========
We discovered three vulnerabilities in systemd-journald (https://en.wikipedia.org/wiki/Systemd):
– CVE-2018-16864 and CVE-2018-16865, two memory corruptions (attacker-controlled alloca()s);</description>
      <content>&lt;p&gt;Des chercheurs de Qualys ont découvert 3 failles de sécurité dans journald qui permet une escalade de privilège. Des PoC ont été fait et cela prend 10minutes sur i386 et 70minutes sur amd64. Attention donc, car tous les patchs ne sont pas encore dispo.&lt;/p&gt;
&lt;p&gt;Ci dessous le résumé provenant de chez qualys:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;========= Summary =========&lt;/p&gt;
&lt;p&gt;We discovered three vulnerabilities in systemd-journald (&lt;a href=&#34;https://en.wikipedia.org/wiki/Systemd)&#34;&gt;https://en.wikipedia.org/wiki/Systemd)&lt;/a&gt;:&lt;/p&gt;
&lt;p&gt;– CVE-2018-16864 and CVE-2018-16865, two memory corruptions (attacker-controlled alloca()s);&lt;/p&gt;
&lt;p&gt;– CVE-2018-16866, an information leak (an out-of-bounds read).&lt;/p&gt;
&lt;p&gt;CVE-2018-16864 was introduced in April 2013 (systemd v203) and became exploitable in February 2016 (systemd v230). We developed a proof of concept for CVE-2018-16864 that gains eip control on i386.&lt;/p&gt;
&lt;p&gt;CVE-2018-16865 was introduced in December 2011 (systemd v38) and became exploitable in April 2013 (systemd v201).&lt;/p&gt;
&lt;p&gt;CVE-2018-16866 was introduced in June 2015 (systemd v221) and was inadvertently fixed in August 2018.&lt;/p&gt;
&lt;p&gt;We developed an exploit for CVE-2018-16865 and CVE-2018-16866 that obtains a local root shell in 10 minutes on i386 and 70 minutes on amd64, on average. We will publish our exploit in the near future.&lt;/p&gt;
&lt;p&gt;To the best of our knowledge, all systemd-based Linux distributions are vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not exploitable because their user space is compiled with GCC’s -fstack-clash-protection.&lt;/p&gt;
&lt;p&gt;This confirms &lt;a href=&#34;https://grsecurity.net/an&#34;&gt;https://grsecurity.net/an&lt;/a&gt;_ancient_kernel_hole_is_not_closed.php: « It should be clear that kernel-only attempts to solve [the Stack Clash] will necessarily always be incomplete, as the real issue lies in the lack of stack probing. »&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;L’intégration de systemd dans les distributions linux il y a plusieurs années avait fait pas mal débat.&lt;/p&gt;
&lt;p&gt;Le fait qu’il soit en rupture avec le principe initial d’unix sur le découpages des tâches avait provoqué pas mal d’émotions.&lt;/p&gt;
&lt;p&gt;Je ne parle pas du fait qu’on est passé d’un system d’init avec des scripts shell à des fichiers ini, des logs binaires et pas mal d’intégration de fonctions qui dépassent l’init comme : les logs system, les cgroup, Resource accounting User session management, mise en veille, synchro du temps, résolution DNS, la découverte des disques etc.&lt;/p&gt;
&lt;p&gt;L’effet de bord et qu’udev a du évoluer et systemd en est devenu un prérequis… la boucle était bouclée.&lt;/p&gt;
&lt;p&gt;Poussé par RedHat, systemd a été intégré dans la majeure partie des distrbution. Gentoo et slackware font partie des rares courageuses exeptions et ne sont donc pas concernées par ces bugs 😉&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://www.qualys.com/2019/01/09/system-down/system-down.txt&#34;&gt;https://www.qualys.com/2019/01/09/system-down/system-down.txt&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://security-tracker.debian.org/tracker/CVE-2018-16864&#34;&gt;https://security-tracker.debian.org/tracker/CVE-2018-16864&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://security-tracker.debian.org/tracker/CVE-2018-16865&#34;&gt;https://security-tracker.debian.org/tracker/CVE-2018-16865&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://security-tracker.debian.org/tracker/CVE-2018-16866&#34;&gt;https://security-tracker.debian.org/tracker/CVE-2018-16866&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</content>
    </item>
    
  </channel>
</rss>
