Hello list,
One of our bash-scrips failed with very low frequency but randomly. The result
was that exactly 1 byte was lost, so the string returned by "read -t 1" was too
short. The culprit seems to be the built-in read function itself, the
probability of failure was about 1:100000 in our case.
After analysis and creation of a reliable reproducer, I'm not sure if this is a
programming error in bash or a bug in our script as the result of suboptimal
documentation.
* Description:
When "read" builtin is used with timeout setting, both with "-t" option or by
setting the "TMOUT" environment variable, and the timeout occurs when some
bytes of line were already received by bash, then those bytes are silently
dropped. The next "read" returns the remainder of the line.
A reproducer for Ubuntu precise is
base64 -d <<BASE64-EOF | tar -xj
QlpoOTFBWSZTWX5lCW0AAOl/xMwQAEB97f//NzycDn/v3uogAAAAgAhAAb1qpgGonpE9TagADQNN
NAAAAaD1AAEomkyGpPKaADQGnqANNPUMmgABoDjJk00wmRkDAjE0YIwg0aYABBJIpphCZiaTNT0h
o0AAAAaaAabU+Cv9dQPcQuSSaABIwQUkQNiTyBFsTAgcG2p0dIEciFV9EZfOok7RyV36nYqnFKSJ
QMO4OAgwMtnhGwTmvZXHNLdCTPwVBN6uopct/CzRFdFSwWj8XJd8plU/gyNLrSlHLzYfHU7wYsAp
zwbepqoV2GJYtNmAVZ1EYAEvzvgNCONxvrT0i4t65SLP1OkisWrcVnuxthOxKiZ5AktJbG2PmccG
IoiA7Mok66IR2eEH5BgUD4BlrvrZmvBaQNmJU3IiUZIPgVFrrcVLRKQTROURx8e14EY40h2oT1c6
APc4kqdy25cqSZh5XelCN0X5EsQUUNkJV9UdtBmLxK8I7iZl/LQ7OQl5PL4YiYMZY04JEXVctElZ
UilWStgdgM7PGQFCLDzmzYbdtnwEQMNC6ai+hyc0swZgkIgj1g05JTBy2CK9O6q+aC4GxU7Q2Uk0
qm1nbfmL0VDEEhOxVhDKbSUgKybpZgyBGTMPaEdGTlNZPC0soGO61Y8pBB/i7kinChIPzKEtoA==
BASE64-EOF
(export TMOUT=1; ./FragmentedSend.py | ./BashReadTest)
* Discussion:
The topic has two aspects:
** What is the intended read behavior in that case, is it a bug?
Man-page is silent on that. So even if current behavior is intended, in my
opinion the possible loss of data in "read" should be mentioned.
-t timeout
Cause read to time out and return failure if a complete
line of input is not read within timeout seconds. time-
out may be a decimal number with a fractional portion
following the decimal point. This option is only effec-
tive if read is reading input from a terminal, pipe, or
other special file; it has no effect when reading from
regular files. If timeout is 0, read returns success if
input is available on the specified file descriptor,
failure otherwise. The exit status is greater than 128
if the timeout is exceeded.
**Mild security aspect:
Since the TMOUT variable might not be filtered when invoking programs via
"sudo" or within other restricted environments, it might be possible for an
unprivileged user to invoke programs that use "read" in the same problematic
way as I did. If he finds ways to influence the timing of the data reaching
this function, he might be able to remove parts of the input or just cause
random data corruption.
I would guess, that it would be a quite rare case, e.g. when someone
implemented following script for login checking
cat [somefile] | sed [regex check for line sanity] | while read authConfLine; do
....Handle it
done
somefile content:
root allprivs Remaining line name of admin
userx someprivs FrankChangedItViaChFn userx allprivs FrankDidIt
Any comments?
Roman
DI Roman Fiedler
Engineer
Safety & Security Department
Assistive Healthcare Information Technology
AIT Austrian Institute of Technology GmbH
Reininghausstrae 13/1 | 8020 Graz | Austria
T +43(0) 50550 2957 | M +43(0) 664 8561599 | F +43(0) 50550 2950
roman.fied...@ait.ac.at | http://www.ait.ac.at/
FN: 115980 i HG Wien | UID: ATU14703506
This email and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information. If you are not the intended recipient, please notify
the sender by return e-mail or by telephone and delete this message from your
system and any printout thereof. Any unauthorized use, reproduction, or
dissemination of this message is strictly prohibited. Please note that e-mails
are susceptible to change. AIT Austrian Institute of Technology GmbH shall not
be liable for the improper or incomplete transmission of the information
contained in this communication, nor shall it be liable for any delay in its
receipt.
