| 2014-10-14 10:28:09 |
Angelo Marletta |
bug |
|
|
added bug |
| 2014-10-14 10:28:09 |
Angelo Marletta |
attachment added |
|
sample stdin https://bugs.launchpad.net/bugs/1381005/+attachment/4235514/+files/attack.txt |
|
| 2014-10-14 22:30:50 |
Angelo Marletta |
information type |
Private Security |
Public Security |
|
| 2014-10-14 22:32:41 |
Angelo Marletta |
information type |
Public Security |
Private Security |
|
| 2014-10-15 02:50:13 |
Angelo Marletta |
description |
Under certain conditions, the input entered from a terminal with a foreground process waiting for stdin, can be interpreted and executed by the shell.
Steps to reproduce:
1) Open a terminal
2) Run a simple program that waits for stdin (like cat, tee, head, tail, ...) or even the bash-builtin command read. No need to specify arguments
3) Type or paste exactly 4096 ASCII characters into the terminal (see sample attachment)
4) Press Enter
What should happen:
The program in foreground reads 4097 characters (the last one is new line).
What actually happens:
Instead of reading the input, the current program exits (read() only reads one character before EOF) and the shell executes the same input starting from the second character.
I believe that the issue can be reproduced with:
- any terminal (tested on xterm, gnome-terminal, tty)
- any shell (tested on bash, zsh)
- any program that reads stdin from terminal (not attached to a pipe)
Debugging the shell with gdb suggests that the bug is in (or under) the implementation of read(), hence the package eglibc.
Specifically, the bug is caused by read() reading only one character (new line) when entering a text of 4096 characters in stdin on the terminal. It looks like read() is then closing the stdin descriptor.
If the input is 4097 characters long, read() will read two characters and the shell will interpret from the 3rd character, and so on.
Verified on OS:
Ubuntu 14.04.1 LTS
Kernel:
3.13.0-24-generic x86_64
3.13.0-36-generic x86_64
Versions of libc6:
2.19-0ubuntu6.1
2.19-0ubuntu6.3
I'm happy to provide more information if it helps.
Angelo |
Under certain conditions, the input entered from a terminal with a foreground process waiting for stdin, can be interpreted and executed by the shell.
Steps to reproduce:
1) Open a terminal
2) Run a simple program that waits for stdin (like cat, tee, head, tail, ...) or even the bash-builtin command read. No need to specify arguments
3) Type or paste exactly 4096 ASCII characters into the terminal (see sample attachment)
4) Press Enter
What should happen:
The program in foreground reads 4097 characters (the last one is new line).
What actually happens:
Instead of reading the input, the current program exits (read() only reads one character before EOF) and the shell executes the same input starting from the second character.
I believe that the issue can be reproduced with:
- any terminal (tested on xterm, gnome-terminal, tty)
- any shell (tested on bash, zsh)
- any program that reads stdin from terminal (not attached to a pipe)
Debugging the shell with gdb suggests that the bug is in (or under) the implementation of read(), hence the package eglibc.
Specifically, the bug is caused by read() reading only one character (new line) when entering a text of 4096 characters in stdin on the terminal. It looks like read() is then closing the stdin descriptor.
If the input is 4097 characters long, read() will read two characters and the shell will interpret from the 3rd character, and so on.
Verified on OS:
Ubuntu 14.04.1 LTS
Kernel:
3.13.0-24-generic x86_64
3.13.0-32-generic x86_64
3.13.0-36-generic x86_64
Versions of libc6:
2.19-0ubuntu6
2.19-0ubuntu6.1
2.19-0ubuntu6.3
I'm happy to provide more information if it helps.
Angelo |
|
| 2014-10-16 05:22:14 |
Angelo Marletta |
affects |
eglibc (Ubuntu) |
ubuntu |
|
| 2014-10-16 05:42:54 |
Angelo Marletta |
description |
Under certain conditions, the input entered from a terminal with a foreground process waiting for stdin, can be interpreted and executed by the shell.
Steps to reproduce:
1) Open a terminal
2) Run a simple program that waits for stdin (like cat, tee, head, tail, ...) or even the bash-builtin command read. No need to specify arguments
3) Type or paste exactly 4096 ASCII characters into the terminal (see sample attachment)
4) Press Enter
What should happen:
The program in foreground reads 4097 characters (the last one is new line).
What actually happens:
Instead of reading the input, the current program exits (read() only reads one character before EOF) and the shell executes the same input starting from the second character.
I believe that the issue can be reproduced with:
- any terminal (tested on xterm, gnome-terminal, tty)
- any shell (tested on bash, zsh)
- any program that reads stdin from terminal (not attached to a pipe)
Debugging the shell with gdb suggests that the bug is in (or under) the implementation of read(), hence the package eglibc.
Specifically, the bug is caused by read() reading only one character (new line) when entering a text of 4096 characters in stdin on the terminal. It looks like read() is then closing the stdin descriptor.
If the input is 4097 characters long, read() will read two characters and the shell will interpret from the 3rd character, and so on.
Verified on OS:
Ubuntu 14.04.1 LTS
Kernel:
3.13.0-24-generic x86_64
3.13.0-32-generic x86_64
3.13.0-36-generic x86_64
Versions of libc6:
2.19-0ubuntu6
2.19-0ubuntu6.1
2.19-0ubuntu6.3
I'm happy to provide more information if it helps.
Angelo |
Under certain conditions, the input entered from a terminal with a foreground process waiting for stdin, can be interpreted and executed by the shell.
Steps to reproduce:
1) Open a terminal
2) Run a simple program that waits for stdin (like cat, tee, head, tail, ...) or even the bash-builtin command read. No need to specify arguments
3) Type or paste exactly 4096 ASCII characters into the terminal (see sample attachment)
4) Press Enter
What should happen:
The program in foreground reads 4097 characters (the last one is new line).
What actually happens:
Instead of reading the input, the current program exits (read() only reads one character before EOF) and the shell executes the same input starting from the second character.
I believe that the issue can be reproduced with:
- any terminal (tested on xterm, gnome-terminal, tty)
- any shell (tested on bash, zsh)
- any program that reads stdin from terminal (not attached to a pipe)
Debugging the shell with gdb suggests that the bug is in the implementation of read(), hence libc6 or under (kernel).
Specifically, the bug is caused by read() reading only one character (new line) when entering a text of 4096 characters in stdin on the terminal. It looks like read() is then closing the stdin descriptor.
If the input is 4097 characters long, read() will read two characters and the shell will interpret from the 3rd character, and so on.
Verified on:
Ubuntu 14.04.1 LTS
Kernel:
3.13.0-24-generic x86_64
3.13.0-32-generic x86_64
3.13.0-36-generic x86_64
libc6:
2.19-0ubuntu6
2.19-0ubuntu6.1
2.19-0ubuntu6.3
I'm happy to provide more information if it helps.
Angelo |
|
| 2014-10-16 05:52:24 |
Angelo Marletta |
information type |
Private Security |
Public Security |
|
| 2014-10-16 13:18:49 |
Launchpad Janitor |
ubuntu: status |
New |
Confirmed |
|
| 2014-11-11 12:37:17 |
Marc Deslauriers |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2014-11-12 17:23:47 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
High |
|
| 2014-11-12 17:23:51 |
Joseph Salisbury |
linux (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2014-11-12 17:24:03 |
Joseph Salisbury |
tags |
|
kernel-da-key trusty |
|
| 2015-01-12 04:17:41 |
Launchpad Janitor |
linux (Ubuntu): status |
Incomplete |
Expired |
|
| 2015-03-27 14:40:58 |
Marc Deslauriers |
linux (Ubuntu): status |
Expired |
Confirmed |
|
| 2015-03-28 01:17:17 |
Joseph Salisbury |
tags |
kernel-da-key trusty |
kernel-da-key trusty utopic vivid |
|
| 2015-03-28 01:17:33 |
Joseph Salisbury |
nominated for series |
|
Ubuntu Trusty |
|
| 2015-03-28 01:17:33 |
Joseph Salisbury |
bug task added |
|
linux (Ubuntu Trusty) |
|
| 2015-03-28 01:17:33 |
Joseph Salisbury |
nominated for series |
|
Ubuntu Vivid |
|
| 2015-03-28 01:17:33 |
Joseph Salisbury |
bug task added |
|
linux (Ubuntu Vivid) |
|
| 2015-03-28 01:17:33 |
Joseph Salisbury |
nominated for series |
|
Ubuntu Utopic |
|
| 2015-03-28 01:17:33 |
Joseph Salisbury |
bug task added |
|
linux (Ubuntu Utopic) |
|
| 2015-03-28 01:17:42 |
Joseph Salisbury |
linux (Ubuntu Trusty): status |
New |
In Progress |
|
| 2015-03-28 01:17:45 |
Joseph Salisbury |
linux (Ubuntu Utopic): status |
New |
In Progress |
|
| 2015-03-28 01:17:48 |
Joseph Salisbury |
linux (Ubuntu Vivid): status |
Confirmed |
In Progress |
|
| 2015-03-28 01:17:51 |
Joseph Salisbury |
linux (Ubuntu Utopic): importance |
Undecided |
High |
|
| 2015-03-28 01:17:53 |
Joseph Salisbury |
linux (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2015-03-28 01:17:55 |
Joseph Salisbury |
linux (Ubuntu Trusty): assignee |
|
Joseph Salisbury (jsalisbury) |
|
| 2015-03-28 01:17:57 |
Joseph Salisbury |
linux (Ubuntu Utopic): assignee |
|
Joseph Salisbury (jsalisbury) |
|
| 2015-03-28 01:18:00 |
Joseph Salisbury |
linux (Ubuntu Vivid): assignee |
|
Joseph Salisbury (jsalisbury) |
|
| 2015-04-15 15:31:26 |
Joseph Salisbury |
linux (Ubuntu Trusty): status |
In Progress |
Confirmed |
|
| 2015-04-16 18:56:35 |
Joseph Salisbury |
linux (Ubuntu Trusty): status |
Confirmed |
In Progress |
|
| 2015-05-18 14:18:03 |
Andy Whitcroft |
linux (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2015-06-01 09:27:43 |
Luis Henriques |
tags |
kernel-da-key trusty utopic vivid |
kernel-da-key trusty utopic verification-needed-trusty vivid |
|
| 2015-06-08 17:18:08 |
Joseph Salisbury |
tags |
kernel-da-key trusty utopic verification-needed-trusty vivid |
kernel-da-key trusty utopic verification-done-trusty vivid |
|
| 2015-06-10 15:26:42 |
Launchpad Janitor |
linux (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2015-06-10 15:26:42 |
Launchpad Janitor |
cve linked |
|
2015-4036 |
|
| 2015-06-10 15:26:42 |
Launchpad Janitor |
linux (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2015-07-06 02:53:35 |
Mathew Hodson |
cve unlinked |
2015-4036 |
|
|
| 2016-04-24 10:43:11 |
Rolf Leggewie |
linux (Ubuntu Utopic): status |
In Progress |
Won't Fix |
|
| 2017-10-17 14:28:38 |
Andy Whitcroft |
linux (Ubuntu Vivid): status |
In Progress |
Won't Fix |
|
| 2019-01-09 16:38:09 |
Joseph Salisbury |
linux (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-07-24 20:55:30 |
Brad Figg |
tags |
kernel-da-key trusty utopic verification-done-trusty vivid |
cscc kernel-da-key trusty utopic verification-done-trusty vivid |
|
