| 2014-09-18 15:04:43 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2014-09-18 15:05:20 |
Jamie Strandboge |
summary |
information disclosure: clipboard contents can be leaked to other applications |
information disclosure: clipboard contents can be obtained in the background |
|
| 2014-09-18 15:09:14 |
Jamie Strandboge |
bug task added |
|
mir (Ubuntu) |
|
| 2014-09-18 15:09:35 |
Jamie Strandboge |
bug task added |
|
content-hub (Ubuntu) |
|
| 2014-09-18 15:10:17 |
Jamie Strandboge |
content-hub (Ubuntu): importance |
Undecided |
High |
|
| 2014-09-18 15:10:21 |
Jamie Strandboge |
mir (Ubuntu): importance |
Undecided |
High |
|
| 2014-09-18 15:10:26 |
Jamie Strandboge |
unity8 (Ubuntu): importance |
Undecided |
High |
|
| 2014-09-18 15:13:16 |
Jamie Strandboge |
description |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard. |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible. |
|
| 2014-09-18 15:13:26 |
Jamie Strandboge |
tags |
|
application-confinement |
|
| 2014-09-18 15:13:36 |
Jamie Strandboge |
information type |
Public |
Public Security |
|
| 2014-09-18 15:13:51 |
Jamie Strandboge |
summary |
information disclosure: clipboard contents can be obtained in the background |
information disclosure: clipboard contents can be obtained without user knowledge |
|
| 2014-09-18 15:21:35 |
Jamie Strandboge |
description |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible. |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access.
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible. |
|
| 2014-09-18 15:22:15 |
Jamie Strandboge |
bug task added |
|
apparmor-easyprof-ubuntu (Ubuntu) |
|
| 2014-09-18 15:22:35 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): importance |
Undecided |
High |
|
| 2014-09-18 15:22:44 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): status |
New |
Triaged |
|
| 2014-09-18 15:28:58 |
Jamie Strandboge |
description |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access.
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible. |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access. Background apps should not be allowed to push content into the clipboard (application lifecycle deals with this, but we need this for the future).
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible. |
|
| 2014-09-18 15:30:58 |
Daniel d'Andrada |
bug |
|
|
added subscriber Daniel d'Andrada |
| 2014-10-06 07:48:58 |
Daniel van Vugt |
bug task added |
|
mir |
|
| 2014-10-06 19:59:04 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): status |
Triaged |
In Progress |
|
| 2014-10-06 19:59:09 |
Jamie Strandboge |
apparmor-easyprof-ubuntu (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2014-10-08 02:07:57 |
Launchpad Janitor |
apparmor-easyprof-ubuntu (Ubuntu): status |
In Progress |
Fix Released |
|
| 2014-10-22 12:46:17 |
Marc Deslauriers |
description |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access. Background apps should not be allowed to push content into the clipboard (application lifecycle deals with this, but we need this for the future).
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible. |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access. Background apps should not be allowed to push content into the clipboard (application lifecycle deals with this, but we need this for the future).
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible.
Another idea is to implement paste in the input method menu, and make that the official way for users to paste inside applications, rather than use menu items or toolbar buttons. |
|
| 2014-10-22 13:29:57 |
Jamie Strandboge |
description |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access. Background apps should not be allowed to push content into the clipboard (application lifecycle deals with this, but we need this for the future).
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible.
Another idea is to implement paste in the input method menu, and make that the official way for users to paste inside applications, rather than use menu items or toolbar buttons. |
Currently, the clipboard is implemented such that all apps can access the contents at any time. The clipboard contents should only be given to apps based on user driven input (eg, a paste operation).
Attack scenario:
1. user launches malicious app 'baz' that polls the clipboard for contents
2. user launches legitimate app 'foo', at which point 'baz' is backgrounded
3. user selects some text and puts it into the clipboard
4. user opens legitimate app 'bar' and pastes text
5. user foregrounds 'baz' which now has access to the clipboard contents
In the above, users can understand that 'foo' and 'bar' have access to the text put in the clipboard. However, it is unexpected that 'baz' also has access since the user didn't paste the text into it.
As it is currently implemented, there is no clipboard timeout, so the contents will persist through the session (unless changed by another copy operation). Application lifecycle will help a little, but not fully since whenever an app is foregrounded, it can the contents of the keyboard.
In the short term, we should require that only a foregrounded app whould be able to get clipboard contents. Push helpers should have an explicit deny to the (upcoming) DBus clipboard access. Background apps should not be allowed to push content into the clipboard (application lifecycle deals with this, but we need this for the future).
Ideally this would be handled via wholly user-driven interactions. While this could be achieved via keyboard driven interactions, it is difficult with toolkit driven interactions (ie, 'Paste' from a menu is necessarily a pull operation). One idea is not to block access but instead make users aware of the clipboard access (eg, an overlay that says "Pasted from clipboard" and then fades out)-- this should be as unobtrusive as possible.
Another idea is to implement paste in the input method menu, and make that the official way for users to paste inside applications, rather than use menu items or toolbar buttons. (Ie, remove the DBus clipboard support and implement this instead. At that point, apparmor-easyprof-ubuntu can remove the (now unused) DBus clipboard access). |
|
| 2014-10-30 08:41:25 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/apparmor-easyprof-ubuntu |
|
| 2014-12-02 01:37:57 |
Daniel van Vugt |
mir: status |
New |
Incomplete |
|
| 2014-12-02 01:38:00 |
Daniel van Vugt |
mir (Ubuntu): status |
New |
Incomplete |
|
| 2014-12-03 13:39:44 |
Jamie Strandboge |
mir (Ubuntu): status |
Incomplete |
New |
|
| 2014-12-03 13:39:46 |
Jamie Strandboge |
mir: status |
Incomplete |
New |
|
| 2016-03-10 11:11:12 |
Albert Astals Cid |
bug |
|
|
added subscriber Albert Astals Cid |
| 2016-03-10 11:11:35 |
Albert Astals Cid |
bug task added |
|
canonical-devices-system-image |
|
| 2016-03-10 11:13:39 |
Albert Astals Cid |
unity8 (Ubuntu): status |
New |
Invalid |
|
| 2016-03-11 19:56:48 |
Pat McGowan |
canonical-devices-system-image: status |
New |
Confirmed |
|
| 2016-03-11 19:56:48 |
Pat McGowan |
canonical-devices-system-image: assignee |
|
Thomas Voß (thomas-voss) |
|
| 2016-10-27 05:39:47 |
doniks |
bug |
|
|
added subscriber krusty |
| 2018-09-17 09:52:08 |
Alex Murray |
content-hub (Ubuntu): status |
New |
Won't Fix |
|
| 2018-09-17 09:52:16 |
Alex Murray |
mir (Ubuntu): status |
New |
Confirmed |
|
| 2018-09-17 09:52:33 |
Alex Murray |
canonical-devices-system-image: status |
Confirmed |
Invalid |
|
