From unknown Sun Jun 22 08:08:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#41456: fix cases where insecure randomness could be used Resent-From: Taylor Hornby Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 22 May 2020 13:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 41456 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 41456@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.159015487532610 (code B ref -1); Fri, 22 May 2020 13:42:01 +0000 Received: (at submit) by debbugs.gnu.org; 22 May 2020 13:41:15 +0000 Received: from localhost ([127.0.0.1]:58476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jc7vG-0008Ts-Oq for submit@debbugs.gnu.org; Fri, 22 May 2020 09:41:15 -0400 Received: from lists.gnu.org ([209.51.188.17]:50970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jc1xp-0000sI-Ej for submit@debbugs.gnu.org; Fri, 22 May 2020 03:19:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jc1xp-00081w-9g for bug-coreutils@gnu.org; Fri, 22 May 2020 03:19:29 -0400 Received: from mail-qv1-xf2a.google.com ([2607:f8b0:4864:20::f2a]:41688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jc1xo-0006SX-41 for bug-coreutils@gnu.org; Fri, 22 May 2020 03:19:29 -0400 Received: by mail-qv1-xf2a.google.com with SMTP id v15so4298727qvr.8 for ; Fri, 22 May 2020 00:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defuse-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ANaHglKSejNwjWQGhmrKGI0QkDaVrtqX2nwo+7PYaHc=; b=luuXWX0KZLfWBBoccayvCu4A3G5god2gnm7+Yd2N6jMHepoKj8wy89bgobcRm8mSeC fz/PXflK+XGsnOZjQOgbLjsGfC2pUUv71YZvzh+D/nYGrMq6vLlRhwOl5/LN/8wtH/SF lr9QCOCcKSstOGeMGbR+Jc8p9zoLiAggVBMgb+inEF0KVgf61zOpHB6eJXRc/T4RHRVh HKg+hXoyQZuqw3u3x2U6+1LcCNkfVV6l9/G5JHNauf98QKX3WPCUIAO2evuuo07MzIe9 mgvzP1Kn1q/p7wcUncwOvTTqiGnBgN3RDd9jPZZq3tXF1t3/noWUGTNURkhFP049Nk5Y 4J+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ANaHglKSejNwjWQGhmrKGI0QkDaVrtqX2nwo+7PYaHc=; b=eAqoM2//QLKR1WN2I4gKRhJhqP7QOBgW7jHAIBJVwRbL1ZqcxT4EBl6+OP3WQDQkZK 9qOZnbhyghCW9/xgqD2qNw6sGG8o+D2Smar78xeqzAnfurgm+nBDgnWZIaGeXJoEpHQ7 hus1R6sLO8gzSqbZ9SjIXCzlEUbYlxC1vgcnVXVecfJnUHGYYp7JIQgNFUtAigklzkSC ESJae1QrX8nEJVi/kZdhdOpdcK8AGCCvffxbOKHQEOyegN8dBI4MwXPIeDU20CNb1lD6 +G31HgR9j00TaMLJth4VeAvmVO6iMI02/fJ4ofye+jQ8390wju8DdnkMhKrGgqwEDQ3a IofA== X-Gm-Message-State: AOAM531tgx8C8z6eJhD4rPLv1JyQ6ehdq3KxNDgM87nVVJXrqwrcLziu SCB55cHDmk7jy8vzKjDZNQHW85rSk1qGpmIN/KDta9WdAFjNaw== X-Google-Smtp-Source: ABdhPJyez/Ha0va6ow/tmn8S/8KXrYiOjKFn1lcE4esqamRd2zictMbOREP3iRYbbsOqzAVMYyNSwIA6TrjsClS/WRo= X-Received: by 2002:a0c:aa85:: with SMTP id f5mr2421050qvb.51.1590131966284; Fri, 22 May 2020 00:19:26 -0700 (PDT) MIME-Version: 1.0 From: Taylor Hornby Date: Fri, 22 May 2020 01:19:15 -0600 Message-ID: Content-Type: multipart/alternative; boundary="000000000000ff2fa805a63772b5" Received-SPF: pass client-ip=2607:f8b0:4864:20::f2a; envelope-from=th@bqp.io; helo=mail-qv1-xf2a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: -1.1 (-) X-Mailman-Approved-At: Fri, 22 May 2020 09:41:13 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --000000000000ff2fa805a63772b5 Content-Type: text/plain; charset="UTF-8" I reported a potential security bug on GitHub: https://github.com/coreutils/coreutils/pull/32. To save you a click, I'll copy-paste it here (for context this is on a PR with a fix): Comment #1: Apologies for submitting on GitHub, it's so much more convenient. I will understand if no one sees this because I didn't follow the guidelines. Justification: - The existing code is dangerous because it can silently fail to seed the random number generator securely, either when fopen() fails or when read() returns fewer bytes than requested, which can happen if the call is interrupted by an interrupt. This is important for utilities like shred where cryptographic-quality randomness is important. - I removed the bytes_bound stuff because it didn't seem necessary anywhere it was used, and if get_nonce is ever called with bytes_bound < bufsize, then part of ISAAC's initial state will contain timestamps/PIDs, so it will not be uniformly random. Usually, stream ciphers like ISAAC require their initial state to be uniformly random, otherwise there will be statistical biases in the early output. I have not tested all the utilities this affects. (Full disclosure is appropriate in this case because any damage has already been done, fixing the problem in secret would not stop any attacks, but disclosing might encourage users to stop using the dangerous code and upgrade.) Comment #2: This is a more serious issue on Solars, which apparently has a blocking /dev/random and NAME_OF_NONCE_DEVICE defaults to /dev/random (see gc-random.m4), or when NAME_OF_NONCE_DEVICE is overriden to /dev/random with a configure flag on a Linux system. I ran some experiments on a Debian 9 box, and read() from /dev/random frequently returns very few bytes, sometimes as few as just 6 bytes. This means, ironically, if someone built the code with /dev/random thinking it would be more secure, it's actually less secure, because read() will return fewer bytes and then very little of the ISAAC seed will be random and most of it will be timestamp/PID/uninitialized memory. Regards, -Taylor --000000000000ff2fa805a63772b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I reported a potential security bug on GitHub:=C2=A0https://github.com/cor= eutils/coreutils/pull/32. To save you a click, I'll copy-paste it h= ere (for context this is on a PR with a fix):

Comment #1= :

Apologies for submitting on GitHub, it's so = much more convenient. I will understand if no one sees this because I didn't follow the guidelines.=

Justification:
  • The existing code is dangerous because it can silently fail to seed the= random number generator securely, either when fopen() fails o= r when read() returns fewer bytes than requested, which can happen if the call is=20 interrupted by an interrupt. This is important for utilities like shr= ed where cryptographic-quality randomness is important.
  • I removed the bytes_bound stuff because it didn't seem= necessary anywhere it was used, and if get_nonce is ever call= ed with bytes_bound < bufsize, then part of ISAAC's initial state will contain timestamps/PIDs, so it= =20 will not be uniformly random. Usually, stream ciphers like ISAAC require their initial state to be uniformly random, otherwise there will be=20 statistical biases in the early output.

I have not tested all the utilities this affects.

(Full disclosure is appropriate in this case because any damage has=20 already been done, fixing the problem in secret would not stop any=20 attacks, but disclosing might encourage users to stop using the=20 dangerous code and upgrade.)

Comment #2:

This is a more serious= issue on Solars, which apparently has a blocking /dev/rand= om and NAME_OF_NONCE_DEVICE defaults to /dev/random<= /code> (see gc-random.m4), or when NAME_OF_NONCE_DEVICE<= /code> is overriden to /dev/random with a configure flag on a = Linux system.

I ran some experiments on a Debian 9 box, and read() fr= om /dev/random frequently returns very few bytes, sometimes as= few as just 6 bytes. This means, ironically, if someone built the code wit= h /dev/random thinking it would be more secure, it's actua= lly less secure, because read() will return fewer bytes and then very little of the ISAAC seed will be=20 random and most of it will be timestamp/PID/uninitialized memory.

Reg= ards,

-Taylor

--000000000000ff2fa805a63772b5-- From unknown Sun Jun 22 08:08:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#41456: fix cases where insecure randomness could be used Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 22 May 2020 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41456 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Taylor Hornby , 41456@debbugs.gnu.org Received: via spool by 41456-submit@debbugs.gnu.org id=B41456.15901570604925 (code B ref 41456); Fri, 22 May 2020 14:18:01 +0000 Received: (at 41456) by debbugs.gnu.org; 22 May 2020 14:17:40 +0000 Received: from localhost ([127.0.0.1]:59941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jc8UV-0001HN-UY for submit@debbugs.gnu.org; Fri, 22 May 2020 10:17:40 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:50779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jc8UU-0001H7-DK for 41456@debbugs.gnu.org; Fri, 22 May 2020 10:17:38 -0400 Received: by mail-wm1-f52.google.com with SMTP id v19so3000606wmj.0 for <41456@debbugs.gnu.org>; Fri, 22 May 2020 07:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UKr90H1liiZc/Dwdkofz8ZZwm619bCjAcdfizMvTl4w=; b=Nbsy2pF9rg51FqSfX+G6rQdLbcIZ14Pxqzcr0nRQR8rPRdA0tpKa3FRTGJ47ZMjXCI AETrA08/dTHewLLbUUajZka9JMJjHlYTFmKYe4rVAEpN2Ee9AYD61p7kUPekmQYzW2tA AQhxjSMXH1bYiNVTlc15JNESGPQkY7b6VphU0kfRBf4pZ9frJJYQ+VlnRN6SYrpmvowQ TNGGt4XANK3nlEVYnJnjztFv8lIphHdgK+B93bod4vavuWPpkPl9395hzRR4ncj4VLT6 G6RmJ9Q/x4+rMy4CmG9uwgEWzX7oQ81/T/iKHKhf1O3TOcr90PjRq5gyeOTrGR1FdbnV jhAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UKr90H1liiZc/Dwdkofz8ZZwm619bCjAcdfizMvTl4w=; b=VHDox/fm2D+m+5eNkZpia4UOT/E5/oPTvm7VZPcCtU+ie7TQUa9mlzOHyRp6XliYFg zqJhtfnXFlQ0VQ5FlMRs+7QOfy4QDrneDp69IEhtEyrH/l1X082BqyHmGzZL6JE3RPg6 6NCMXGrAXRYOe4mvTztpaF2SxMN1YRz/WY8t1UrS/BvTTNrReD34tdpFGt2I60AUChhE 11Bif4U4iaB2aXK8jugJczZX/i0KAgPeHP//B++8cxCM+KAo1MXu0JE71+LMJ3Z5X7YT W/n3UteXcaOXX6PuWcJG4ePSWMHjGJjg5g+PULlgm0slWaq/DR/4ydAhiBJyC+ORfJut 7MyA== X-Gm-Message-State: AOAM533J0YwBn+Ggy5GhL90nePDmrWLZaRfDtv755iU1eSAdtP1fSSND mLTvn6r6lT9JyMQEQohdADXUBfX+ X-Google-Smtp-Source: ABdhPJxVkYFoVrOwWWnigNJ1mprEn2Qg9aGf1465IjVvuBXUUsfk3YPO4cq8khF1G1OwX6reAmmmIQ== X-Received: by 2002:a7b:cf22:: with SMTP id m2mr14383256wmg.82.1590157051752; Fri, 22 May 2020 07:17:31 -0700 (PDT) Received: from localhost.localdomain (86-42-14-227-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.42.14.227]) by smtp.googlemail.com with ESMTPSA id p10sm10086183wra.78.2020.05.22.07.17.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2020 07:17:31 -0700 (PDT) References: From: =?UTF-8?Q?P=C3=A1draig?= Brady Message-ID: <89588b40-337e-94e8-75a1-c45889bd9479@draigBrady.com> Date: Fri, 22 May 2020 15:17:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Thunderbird/76.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 22/05/2020 08:19, Taylor Hornby wrote: > I reported a potential security bug on GitHub: > https://github.com/coreutils/coreutils/pull/32. To save you a click, I'll > copy-paste it here (for context this is on a PR with a fix): > > Comment #1: > > Apologies for submitting on GitHub, it's so much more convenient. I will > understand if no one sees this because I didn't follow the guidelines. > > Justification: > > - The existing code is dangerous because it can silently fail to seed > the random number generator securely, either when fopen() fails or when > read() returns fewer bytes than requested, which can happen if the call > is interrupted by an interrupt. This is important for utilities like > shred where cryptographic-quality randomness is important. > - I removed the bytes_bound stuff because it didn't seem necessary > anywhere it was used, and if get_nonce is ever called with bytes_bound < > bufsize, then part of ISAAC's initial state will contain > timestamps/PIDs, so it will not be uniformly random. Usually, stream > ciphers like ISAAC require their initial state to be uniformly random, > otherwise there will be statistical biases in the early output. > > I have not tested all the utilities this affects. > > (Full disclosure is appropriate in this case because any damage has already > been done, fixing the problem in secret would not stop any attacks, but > disclosing might encourage users to stop using the dangerous code and > upgrade.) > > Comment #2: > > This is a more serious issue on Solars, which apparently has a blocking > /dev/random > and NAME_OF_NONCE_DEVICE defaults to /dev/random (see gc-random.m4), or > when NAME_OF_NONCE_DEVICE is overriden to /dev/random with a configure flag > on a Linux system. > > I ran some experiments on a Debian 9 box, and read() from /dev/random > frequently returns very few bytes, sometimes as few as just 6 bytes. This > means, ironically, if someone built the code with /dev/random thinking it > would be more secure, it's actually less secure, because read() will return > fewer bytes and then very little of the ISAAC seed will be random and most > of it will be timestamp/PID/uninitialized memory. Testing on a Solaris 10 box indicates that /dev/random doesn't give short reads. All other systems default to /dev/urandom. coreutils doesn't need cryptographic randomness, so the read from /dev/urandom should be seen as optional, and present to improve randomness when available. I'm not sure your concerns are justified in the coreutils context. cheers, Pádraig From unknown Sun Jun 22 08:08:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#41456: fix cases where insecure randomness could be used Resent-From: Taylor Hornby Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 22 May 2020 15:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41456 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 41456@debbugs.gnu.org Received: via spool by 41456-submit@debbugs.gnu.org id=B41456.159016272830430 (code B ref 41456); Fri, 22 May 2020 15:53:02 +0000 Received: (at 41456) by debbugs.gnu.org; 22 May 2020 15:52:08 +0000 Received: from localhost ([127.0.0.1]:60084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jc9xv-0007uj-OI for submit@debbugs.gnu.org; Fri, 22 May 2020 11:52:08 -0400 Received: from mail-qv1-f65.google.com ([209.85.219.65]:47023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jc9tP-0007Y4-3Y for 41456@debbugs.gnu.org; Fri, 22 May 2020 11:47:27 -0400 Received: by mail-qv1-f65.google.com with SMTP id dh1so4886082qvb.13 for <41456@debbugs.gnu.org>; Fri, 22 May 2020 08:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defuse-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XDo90xscj+H9huIog+Hdk7YVn+MydCQObBqLHVgfRKg=; b=ThxYoA7aIovV1NCc+hsRkR5JfOsLTkiMJefSetXUuDRFh7LnxIo6+84C7v8ZrL9H1o FebYuF9mJGkfUNJDofKizT2woGvZknX69NczlIqIINX0hJa7FHpkqMchEUFRefHaMwR2 6hdVFkKsb+Hc7oTdgywdhyeF1P8sEVJA6HqqMde9MF92kpLfQMA+qWtMadmxpUpTbFmZ 3DqB2ZeKr2SeBsLTk9l9k17rF0ysjnj+ndTYDJuu/YfvQO2KQNPnE/bDTVymdpjRZXuz OKBaJUYuM/ulJbEuJt9J1ZxWXfeJChqkFqVnIxygsfdc9thyOYGeRhf2h15/iAfYGp02 RddA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XDo90xscj+H9huIog+Hdk7YVn+MydCQObBqLHVgfRKg=; b=WfdrucSVbEOtzAO9E1JhOe69NP2yyQhQmm+TXuunNmehsl8wlh+m01M+s4lIK0EX7X 9V+Fjs8YvyaP3Zk0fu5D3Edg9hcN1LqNG/l2+fkbskORRAc51aa/tG0QSFKbWKtdFwT0 vnEU8a5Vzhst9tfS3um6JitT1D5+F/9XiTP1A57jnPRIzpn4Dkj/GaC9di6QOSJdSKwn tfDqhgVuf/Pb9ijB1Whxmf0nRK5HRuj7bGtUZav0AjcuXVM6oHCKRgvqRHTO0eu0QJPJ CtgBTCRhltY1X3LSkRXWoN5CeD1f1lMP3UJl9mcMD1bWhYREqfNhF2RreceNSH8t4yMI dBgQ== X-Gm-Message-State: AOAM533MRIXzgRVLlvUJfNnto/R9J+XLr5HB8LE/4OALpnHWrM3emdFp ExWwUnz5Y2p4xZueHRjpLB+shhW1olh5xGVUlpIq6iCNGx0= X-Google-Smtp-Source: ABdhPJzeEm1JMHnnfrvhn5i6ZF8HAECxKIWAkDQBiOCRlbN2SYLAgt2XcZmFaYXnhWptCjPVvTKftLfRY5khMIDivbY= X-Received: by 2002:a0c:aa85:: with SMTP id f5mr4364461qvb.51.1590162441176; Fri, 22 May 2020 08:47:21 -0700 (PDT) MIME-Version: 1.0 References: <89588b40-337e-94e8-75a1-c45889bd9479@draigBrady.com> In-Reply-To: <89588b40-337e-94e8-75a1-c45889bd9479@draigBrady.com> From: Taylor Hornby Date: Fri, 22 May 2020 09:47:10 -0600 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Mailman-Approved-At: Fri, 22 May 2020 11:52:07 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On Fri, May 22, 2020 at 8:17 AM P=C3=A1draig Brady wrote= : > > On 22/05/2020 08:19, Taylor Hornby wrote: > > I reported a potential security bug on GitHub: > > https://github.com/coreutils/coreutils/pull/32. To save you a click, I'= ll > > copy-paste it here (for context this is on a PR with a fix): > > > > Comment #1: > > > > Apologies for submitting on GitHub, it's so much more convenient. I wil= l > > understand if no one sees this because I didn't follow the guidelines. > > > > Justification: > > > > - The existing code is dangerous because it can silently fail to se= ed > > the random number generator securely, either when fopen() fails or = when > > read() returns fewer bytes than requested, which can happen if the = call > > is interrupted by an interrupt. This is important for utilities lik= e > > shred where cryptographic-quality randomness is important. > > - I removed the bytes_bound stuff because it didn't seem necessary > > anywhere it was used, and if get_nonce is ever called with bytes_bo= und < > > bufsize, then part of ISAAC's initial state will contain > > timestamps/PIDs, so it will not be uniformly random. Usually, strea= m > > ciphers like ISAAC require their initial state to be uniformly rand= om, > > otherwise there will be statistical biases in the early output. > > > > I have not tested all the utilities this affects. > > > > (Full disclosure is appropriate in this case because any damage has alr= eady > > been done, fixing the problem in secret would not stop any attacks, but > > disclosing might encourage users to stop using the dangerous code and > > upgrade.) > > > > Comment #2: > > > > This is a more serious issue on Solars, which apparently has a blocking > > /dev/random > > and NAME_OF_NONCE_DEVICE defaults to /dev/random (see gc-random.m4), or > > when NAME_OF_NONCE_DEVICE is overriden to /dev/random with a configure = flag > > on a Linux system. > > > > I ran some experiments on a Debian 9 box, and read() from /dev/random > > frequently returns very few bytes, sometimes as few as just 6 bytes. Th= is > > means, ironically, if someone built the code with /dev/random thinking = it > > would be more secure, it's actually less secure, because read() will re= turn > > fewer bytes and then very little of the ISAAC seed will be random and m= ost > > of it will be timestamp/PID/uninitialized memory. > > Testing on a Solaris 10 box indicates that /dev/random doesn't give short= reads. > All other systems default to /dev/urandom. > coreutils doesn't need cryptographic randomness, so the read from > /dev/urandom should be seen as optional, and present to improve randomnes= s when available. > I'm not sure your concerns are justified in the coreutils context. > Thanks for your reply. Yeah, I really doubt it's a problem for most use cases. However I do use the shred utility in a context that requires high-quality randomness: filling a disk with random data prior to using LUKS encryption. Doing so (with good randomness) makes it impossible to tell which parts of the disk have ciphertext from LUKS and which are "unwritten" (since the randomness pass), preventing a small information leak where you can tell how much & where data exists on the drive. I suppose instead of using shred, I should just do a pass of zeros on the encrypted device, so that it's completely filled with ciphertext. I think at the very least a warning should be added to shred's help output or manpage that its output cannot be relied on to be cryptographically secure. Thanks, -Taylor From unknown Sun Jun 22 08:08:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#41456: fix cases where insecure randomness could be used Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 22 May 2020 16:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41456 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Taylor Hornby Cc: 41456@debbugs.gnu.org Received: via spool by 41456-submit@debbugs.gnu.org id=B41456.15901661013268 (code B ref 41456); Fri, 22 May 2020 16:49:02 +0000 Received: (at 41456) by debbugs.gnu.org; 22 May 2020 16:48:21 +0000 Received: from localhost ([127.0.0.1]:60159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcAqL-0000qd-4x for submit@debbugs.gnu.org; Fri, 22 May 2020 12:48:21 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:55802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcAqJ-0000qQ-Du for 41456@debbugs.gnu.org; Fri, 22 May 2020 12:48:19 -0400 Received: by mail-wm1-f68.google.com with SMTP id f13so9229764wmc.5 for <41456@debbugs.gnu.org>; Fri, 22 May 2020 09:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=J0CZrlg3UizvRdhZLYhEFAbBjWOLQViaSzz+pcm72kY=; b=do/AtsZFNY9IleDRMujZ3NV4fG+aNc2Nn26oTImsSTywik3c3+cHqYSE7qzY1GluEU uisaRj9xxx/Qe8DOeVTjX03wqsw5erj/p3g58VXgU8JIU70jApqmHeOYTYocqJvoBoFM 1veL9vWzC/V+BI82C8OKy/v5DeBo8aZaQ58kOxjlNstW0YTscDmFMVPhXdWQUFPG++Ru mWqxgQGP8pc4jrdjAOkka3gcbARvLMtd3rmdFmpytSj0eecml0oaISIdmW+bLy45yRKE D/hIVGZvPSW2g91/7CPty2lkB5Om3OJ4qElPaTiswtzwBqUwmfxlwMo9y/KlLKG90XHB Zq7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=J0CZrlg3UizvRdhZLYhEFAbBjWOLQViaSzz+pcm72kY=; b=s5iFs+DquZ48r4e+peuNRAZ+C48oWG7e8B1h+dhNH1QyAP0JHVsWnnP41KR2hSeUBC Ljbdy3HnznD+SO/HNkOTPh7VHMedb0N0T8cRBw9J8BZwhGH37GS+onMOwFnarn8/dugE i2JZEzQuZiCyr+BC6+NnTzHBUdIOn72tG6vmm8535r2kCV5RjTqI6QAdBXrstFbaCpZX IJIfA5UpbbJBdUhP8oa+uD1aURRdPkWOyw86f3ahaIZtOia+36VQAMzSu2frhpYEmK+A 441Rec6qC9WWsviPVKGbjrJmbTtN41n6ytyJzFLWhcWUEOW2Ybu1XWVBpLGwvmcffhbe z/7Q== X-Gm-Message-State: AOAM532VpUj7NiJk2Ep6+s7SBqhT5p6+8WNhc2zyNjcTjs8ZQD3PpObi /vKo9on2e3Iew3FlqFOBtBu8174s X-Google-Smtp-Source: ABdhPJzngfKeyhS0RWbmrnE7Dqp9n9N7WxLgMyNWtbO+IT9Rn6BWZHFVkntCnJsLy3M7ZWRQyJl2sA== X-Received: by 2002:a7b:cc88:: with SMTP id p8mr242257wma.104.1590166092985; Fri, 22 May 2020 09:48:12 -0700 (PDT) Received: from localhost.localdomain (86-42-14-227-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.42.14.227]) by smtp.googlemail.com with ESMTPSA id u3sm1027194wrw.89.2020.05.22.09.48.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2020 09:48:12 -0700 (PDT) References: <89588b40-337e-94e8-75a1-c45889bd9479@draigBrady.com> From: =?UTF-8?Q?P=C3=A1draig?= Brady Message-ID: <231972cf-4c3a-5ea0-8a62-80ff3900b50b@draigBrady.com> Date: Fri, 22 May 2020 17:48:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Thunderbird/76.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 22/05/2020 16:47, Taylor Hornby wrote: > On Fri, May 22, 2020 at 8:17 AM Pádraig Brady wrote: >> >> On 22/05/2020 08:19, Taylor Hornby wrote: >>> I reported a potential security bug on GitHub: >>> https://github.com/coreutils/coreutils/pull/32. To save you a click, I'll >>> copy-paste it here (for context this is on a PR with a fix): >>> >>> Comment #1: >>> >>> Apologies for submitting on GitHub, it's so much more convenient. I will >>> understand if no one sees this because I didn't follow the guidelines. >>> >>> Justification: >>> >>> - The existing code is dangerous because it can silently fail to seed >>> the random number generator securely, either when fopen() fails or when >>> read() returns fewer bytes than requested, which can happen if the call >>> is interrupted by an interrupt. This is important for utilities like >>> shred where cryptographic-quality randomness is important. >>> - I removed the bytes_bound stuff because it didn't seem necessary >>> anywhere it was used, and if get_nonce is ever called with bytes_bound < >>> bufsize, then part of ISAAC's initial state will contain >>> timestamps/PIDs, so it will not be uniformly random. Usually, stream >>> ciphers like ISAAC require their initial state to be uniformly random, >>> otherwise there will be statistical biases in the early output. >>> >>> I have not tested all the utilities this affects. >>> >>> (Full disclosure is appropriate in this case because any damage has already >>> been done, fixing the problem in secret would not stop any attacks, but >>> disclosing might encourage users to stop using the dangerous code and >>> upgrade.) >>> >>> Comment #2: >>> >>> This is a more serious issue on Solars, which apparently has a blocking >>> /dev/random >>> and NAME_OF_NONCE_DEVICE defaults to /dev/random (see gc-random.m4), or >>> when NAME_OF_NONCE_DEVICE is overriden to /dev/random with a configure flag >>> on a Linux system. >>> >>> I ran some experiments on a Debian 9 box, and read() from /dev/random >>> frequently returns very few bytes, sometimes as few as just 6 bytes. This >>> means, ironically, if someone built the code with /dev/random thinking it >>> would be more secure, it's actually less secure, because read() will return >>> fewer bytes and then very little of the ISAAC seed will be random and most >>> of it will be timestamp/PID/uninitialized memory. >> >> Testing on a Solaris 10 box indicates that /dev/random doesn't give short reads. >> All other systems default to /dev/urandom. >> coreutils doesn't need cryptographic randomness, so the read from >> /dev/urandom should be seen as optional, and present to improve randomness when available. >> I'm not sure your concerns are justified in the coreutils context. >> > > Thanks for your reply. Yeah, I really doubt it's a problem for most > use cases. However I do use the shred utility in a context that > requires high-quality randomness: filling a disk with random data > prior to using LUKS encryption. Doing so (with good randomness) makes > it impossible to tell which parts of the disk have ciphertext from > LUKS and which are "unwritten" (since the randomness pass), preventing > a small information leak where you can tell how much & where data > exists on the drive. I suppose instead of using shred, I should just > do a pass of zeros on the encrypted device, so that it's completely > filled with ciphertext. I think at the very least a warning should be > added to shred's help output or manpage that its output cannot be > relied on to be cryptographically secure. If you were considering changing from the operations, one could pass --random-source to shred, which will fail as you desire if there is not enough random data. For example you might pass --random-source=/dev/urandom, though noting that this may result in slower operation than the internal PRNG. The default operation is to seed the internal PRNG with 2K of random data from /dev/urandom. I think you're saying that's sufficient for your needs, but if there was ever a short read then the output from coreutils' PRNG would not be sufficient, and distinguishable from real LUKS encrypted data. Have you noticed that with an entropy determination utility? If that was actually the case, then it might be worth issuing a warning upon short/failed read of the default nonce device, as it would be both consequential and unlikely. cheers, Pádraig From unknown Sun Jun 22 08:08:05 2025 X-Loop: help-debbugs@gnu.org Subject: bug#41456: fix cases where insecure randomness could be used Resent-From: Taylor Hornby Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 22 May 2020 17:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41456 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 41456@debbugs.gnu.org Received: via spool by 41456-submit@debbugs.gnu.org id=B41456.15901685407287 (code B ref 41456); Fri, 22 May 2020 17:29:01 +0000 Received: (at 41456) by debbugs.gnu.org; 22 May 2020 17:29:00 +0000 Received: from localhost ([127.0.0.1]:60301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcBTa-0001tN-8A for submit@debbugs.gnu.org; Fri, 22 May 2020 13:28:59 -0400 Received: from mail-qt1-f174.google.com ([209.85.160.174]:36694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcBTZ-0001tA-5B for 41456@debbugs.gnu.org; Fri, 22 May 2020 13:28:53 -0400 Received: by mail-qt1-f174.google.com with SMTP id v4so8916020qte.3 for <41456@debbugs.gnu.org>; Fri, 22 May 2020 10:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defuse-ca.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r/kvE7K0ryNup5sfy1KDQISstPk+Hen6wD0uoLe1Azc=; b=Qv928GIqhcYZdBLItJSIODj2YgCSAJyzvXohEOTLYRiAqYFjZtjv2lOwpolnemgX/M WFC7BBBkQ27fchU90PaNg1MkN7rQpP8YqNTGYtgmScF83d6SOGKjBSwfj5xylsYiUaoC BncSDnoTRX4xmsp5RK/BjhW335ewIOZu6vWjKwc9iwTcsRsIuHmBUuhdOYlUKtD6PRXL nMFdqzDT3PZxgSFTys/OstjviJRH9UHzqdCNIIlomZWiN45Ukk/CnHFr74jJ9Uy9ooq9 FR0CMeximPaSNdpWoU8jvpJsO+y2qBx8CwFZdEfbkg41IqQx7GY6YgEVkPwB5UHho54W VWfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r/kvE7K0ryNup5sfy1KDQISstPk+Hen6wD0uoLe1Azc=; b=bTIVnYzVfAt5bWEkyxdhQOZrMZLSt5jNieoxw7QCddKBtzJK5E7Ln+3AfE0PD5lyMg j5qYfTgu7O9/Xv3hSElcijuGpdGP7e8CYwMPdYrzFiO9jVK6delMpquEtBXVBm771bpX u29OiV2DT+xh4Ho1GHQLPnDEyEd7bOSNGhEuaZzkjdDe3we7zF9XVs4FBeNaPmsz8v27 47El6RI8V4vqqSxgZlt8nC+4O3IaifLtJGUKAHvYV0tSHGkF/tPoLGMJX+6dg4TdNZwq m7MtoIx4OnPD5wl4YdzHjhX3gqq5w1Sx65BS6xpafg2wIgR61Yfa357ftwrGsalsBRds IHSQ== X-Gm-Message-State: AOAM532LzcHimJn8jswPSe1Wxw+RwcyxAs+rbaW5zdInFHC/6iBaStZc 7Fe8/bABrjWJuoYWCD8+fJuX85tT2cK/0aEydtbNxw== X-Google-Smtp-Source: ABdhPJxKyD+oJ1BmSwy3sp5DU/PK7yc0w33sLXxiPmjEy+65D6m6J25Ik/kfjMm8gAZw8f0b0t3kNLod2o79tYIA6Fo= X-Received: by 2002:ac8:4555:: with SMTP id z21mr49592qtn.284.1590168527078; Fri, 22 May 2020 10:28:47 -0700 (PDT) MIME-Version: 1.0 References: <89588b40-337e-94e8-75a1-c45889bd9479@draigBrady.com> <231972cf-4c3a-5ea0-8a62-80ff3900b50b@draigBrady.com> In-Reply-To: <231972cf-4c3a-5ea0-8a62-80ff3900b50b@draigBrady.com> From: Taylor Hornby Date: Fri, 22 May 2020 11:28:36 -0600 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Fri, May 22, 2020 at 10:48 AM P=C3=A1draig Brady wrot= e: > > On 22/05/2020 16:47, Taylor Hornby wrote: > > On Fri, May 22, 2020 at 8:17 AM P=C3=A1draig Brady w= rote: > >> > >> On 22/05/2020 08:19, Taylor Hornby wrote: > >>> I reported a potential security bug on GitHub: > >>> https://github.com/coreutils/coreutils/pull/32. To save you a click, = I'll > >>> copy-paste it here (for context this is on a PR with a fix): > >>> > >>> Comment #1: > >>> > >>> Apologies for submitting on GitHub, it's so much more convenient. I w= ill > >>> understand if no one sees this because I didn't follow the guidelines= . > >>> > >>> Justification: > >>> > >>> - The existing code is dangerous because it can silently fail to= seed > >>> the random number generator securely, either when fopen() fails = or when > >>> read() returns fewer bytes than requested, which can happen if t= he call > >>> is interrupted by an interrupt. This is important for utilities = like > >>> shred where cryptographic-quality randomness is important. > >>> - I removed the bytes_bound stuff because it didn't seem necessa= ry > >>> anywhere it was used, and if get_nonce is ever called with bytes= _bound < > >>> bufsize, then part of ISAAC's initial state will contain > >>> timestamps/PIDs, so it will not be uniformly random. Usually, st= ream > >>> ciphers like ISAAC require their initial state to be uniformly r= andom, > >>> otherwise there will be statistical biases in the early output. > >>> > >>> I have not tested all the utilities this affects. > >>> > >>> (Full disclosure is appropriate in this case because any damage has a= lready > >>> been done, fixing the problem in secret would not stop any attacks, b= ut > >>> disclosing might encourage users to stop using the dangerous code and > >>> upgrade.) > >>> > >>> Comment #2: > >>> > >>> This is a more serious issue on Solars, which apparently has a blocki= ng > >>> /dev/random > >>> and NAME_OF_NONCE_DEVICE defaults to /dev/random (see gc-random.m4), = or > >>> when NAME_OF_NONCE_DEVICE is overriden to /dev/random with a configur= e flag > >>> on a Linux system. > >>> > >>> I ran some experiments on a Debian 9 box, and read() from /dev/random > >>> frequently returns very few bytes, sometimes as few as just 6 bytes. = This > >>> means, ironically, if someone built the code with /dev/random thinkin= g it > >>> would be more secure, it's actually less secure, because read() will = return > >>> fewer bytes and then very little of the ISAAC seed will be random and= most > >>> of it will be timestamp/PID/uninitialized memory. > >> > >> Testing on a Solaris 10 box indicates that /dev/random doesn't give sh= ort reads. > >> All other systems default to /dev/urandom. > >> coreutils doesn't need cryptographic randomness, so the read from > >> /dev/urandom should be seen as optional, and present to improve random= ness when available. > >> I'm not sure your concerns are justified in the coreutils context. > >> > > > > Thanks for your reply. Yeah, I really doubt it's a problem for most > > use cases. However I do use the shred utility in a context that > > requires high-quality randomness: filling a disk with random data > > prior to using LUKS encryption. Doing so (with good randomness) makes > > it impossible to tell which parts of the disk have ciphertext from > > LUKS and which are "unwritten" (since the randomness pass), preventing > > a small information leak where you can tell how much & where data > > exists on the drive. I suppose instead of using shred, I should just > > do a pass of zeros on the encrypted device, so that it's completely > > filled with ciphertext. I think at the very least a warning should be > > added to shred's help output or manpage that its output cannot be > > relied on to be cryptographically secure. > > If you were considering changing from the operations, > one could pass --random-source to shred, which will fail > as you desire if there is not enough random data. > > For example you might pass --random-source=3D/dev/urandom, > though noting that this may result in slower operation > than the internal PRNG. > > The default operation is to seed the internal PRNG with 2K > of random data from /dev/urandom. I think you're saying > that's sufficient for your needs, but if there was ever > a short read then the output from coreutils' PRNG would > not be sufficient, and distinguishable from real LUKS encrypted data. > Have you noticed that with an entropy determination utility? > If that was actually the case, then it might be worth > issuing a warning upon short/failed read of the default nonce device, > as it would be both consequential and unlikely. > Yes that's exactly right. Using /dev/urandom is much slower because of the overhead of having to make system calls, and a properly-seeded ISAAC is safe for this use case while being much faster. Because ISAAC is a stream cipher, its output will look random to statistical analysis tools even when its seed is very simple (e.g. all zeroes or a repeating pattern). The problem is that even though it looks random, when a weak seed is used, there are almost certainly cryptographic attacks that would let you recover the seed from the output, which wouldn't be possible if the seed were random. Furthermore, if the seed were low-enough entropy, like if it were *only* the timestamp and PIDs in the case where open() fails, then you could just brute-force all possible timestamps and PIDs until you find the seed. For the disk-encryption-pre-wiping use case, once you've recovered the seed, you can easily tell which data on the disk is encrypted and which came from ISAAC. I think we should decide whether shred should even support this use case. If it should, then I think it should either do it safely or completely fail, and if not then it should be documented in the help (and maybe added to the list of rejected feature requests). I searched found some posts online (e.g. https://security.stackexchange.com/a/215966) that recommend using shred for this use case, and at least one book that does: https://books.google.ca/books?id=3D8R2CDwAAQBAJ&pg=3DPA299&lpg=3DPA299&dq= =3Dshred+luks+random&source=3Dbl&ots=3DUhdDwvI2N0&sig=3DACfU3U2O-NIKboGKdT_= d1qq1gf_Sqy-QVQ&hl=3Den&sa=3DX&ved=3D2ahUKEwjw1I-5_cfpAhW0FTQIHdOlCf4Q6AEwB= HoECAoQAQ#v=3Donepage&q=3Dshred%20luks%20random&f=3Dfalse But thankfully the vast majority of the posts I found recommend using /dev/urandom directly or shred with --random-source=3D/dev/urandom. -Taylor