| 2009-07-06 02:55:22 |
Stuart Bishop |
bug |
|
|
added bug |
| 2009-07-15 00:45:42 |
Diogo Matsubara |
affects |
launchpad |
launchpad-foundations |
|
| 2009-07-15 00:45:56 |
Diogo Matsubara |
tags |
|
librarian |
|
| 2010-01-25 06:32:54 |
Curtis Hovey |
launchpad-foundations: status |
New |
Triaged |
|
| 2010-01-25 06:32:57 |
Curtis Hovey |
launchpad-foundations: importance |
Undecided |
Low |
|
| 2010-09-03 08:40:45 |
Robert Collins |
summary |
'private' Librarian opens us to security vulnerabilities |
exposing user supplied files in the launchpad appserver domain opens us to security vulnerabilities |
|
| 2010-09-03 08:40:49 |
Robert Collins |
description |
The production Librarian runs on a non-launchpad.net domain. This means that if a HTML document or other content that can embed commands is served, the browser security model should stop it stealing authentication credentials.
We are now proxying some files via Launchpad - stuff served from the 'private' Librarian. The current pattern is that these files are served from the launchpad.net domain. If we neglect to whitelist the type of user provided files that can be served from launchpad.net, or browser bugs allow whitelisted content to be executed by the browser, we open ourselves to attack such as having authentication tokens stolen.
We need a pattern that is secure by default so that when more content is migrated to the 'private' Librarian (bug attachments for instance), we don't shoot ourselves in the foot. |
The production Librarian runs on a non-launchpad.net domain. This means that if a HTML document or other content that can embed commands is served, the browser security model should stop it stealing authentication credentials.
We are now proxying some files via Launchpad - stuff served from the 'private' Librarian. The current pattern is that these files are served from the launchpad.net domain. If we neglect to whitelist the type of user provided files that can be served from launchpad.net, or browser bugs allow whitelisted content to be executed by the browser, we open ourselves to attack such as having authentication tokens stolen.
We need a pattern that is secure by default so that when more content is migrated to the 'private' Librarian (bug attachments for instance), we don't shoot ourselves in the foot.
|
|
| 2010-09-03 08:51:12 |
Robert Collins |
summary |
exposing user supplied files in the launchpad appserver domain opens us to security vulnerabilities |
proxying user supplied files via the launchpad appserver domain has security and performance issues |
|
| 2010-09-03 08:55:18 |
Robert Collins |
description |
The production Librarian runs on a non-launchpad.net domain. This means that if a HTML document or other content that can embed commands is served, the browser security model should stop it stealing authentication credentials.
We are now proxying some files via Launchpad - stuff served from the 'private' Librarian. The current pattern is that these files are served from the launchpad.net domain. If we neglect to whitelist the type of user provided files that can be served from launchpad.net, or browser bugs allow whitelisted content to be executed by the browser, we open ourselves to attack such as having authentication tokens stolen.
We need a pattern that is secure by default so that when more content is migrated to the 'private' Librarian (bug attachments for instance), we don't shoot ourselves in the foot.
|
The production Librarian runs on a non-launchpad.net domain. This means that if a HTML document or other content that can embed commands is served, the browser security model should stop it stealing authentication credentials.
We are now proxying some files via Launchpad - stuff served from the 'restricted' Librarian. The current pattern is that these files are served from the launchpad.net domain. We use SafeStreamingOrRedirectFileAlias to serve user supplied files, and Streaming... to serve internally generated files.
However this has some issues: we cannot do inline rendering of user supplied files because they could attack launchpad cookies, perform AJAX and so on; its also non scalable and makes the appservers fragile due to downloading directly from the librarian.
OpenID and other cookie based solutions cannot help, because those cookies would be vulnerable to attack; we need something that partitions all user supplied content into one security context each.
The current plan is to use a separate domain using wildcard DNS, per contenthash (LFC object), on https, with a random token providing time limited access; tokens will be generated by the appservers even in readonly requests, and the librarian will check for tokens on all LFAs which have the restricted bit set.
https://code.edge.launchpad.net/~lifeless/launchpad/private-librarian/+merge/31020 details this approach.
|
|
| 2010-09-03 08:55:21 |
Robert Collins |
launchpad-foundations: importance |
Low |
High |
|
| 2010-09-03 08:57:01 |
Robert Collins |
visibility |
private |
public |
|
| 2010-09-03 08:57:01 |
Robert Collins |
security vulnerability |
yes |
no |
|
| 2010-09-03 09:04:30 |
Robert Collins |
branch linked |
|
lp:~lifeless/launchpad/private-librarian |
|
| 2010-09-03 09:04:59 |
Abel Deuring |
bug |
|
|
added subscriber Abel Deuring |
| 2010-09-06 22:56:29 |
Robert Collins |
launchpad-foundations: assignee |
|
Robert Collins (lifeless) |
|
| 2010-09-09 16:06:34 |
Ursula Junque |
launchpad-foundations: status |
Triaged |
Fix Committed |
|
| 2010-09-09 16:06:38 |
Ursula Junque |
launchpad-foundations: milestone |
|
10.09 |
|
| 2010-09-09 16:09:43 |
Ursula Junque |
tags |
librarian |
librarian qa-needstesting |
|
| 2010-09-19 06:59:09 |
Robert Collins |
summary |
proxying user supplied files via the launchpad appserver domain has security and performance issues |
proxying user supplied libarian files via the launchpad appserver domain has security and performance issues |
|
| 2010-09-19 06:59:12 |
Micah Gersten |
bug |
|
|
added subscriber Micah Gersten |
| 2010-09-19 06:59:43 |
Robert Collins |
description |
The production Librarian runs on a non-launchpad.net domain. This means that if a HTML document or other content that can embed commands is served, the browser security model should stop it stealing authentication credentials.
We are now proxying some files via Launchpad - stuff served from the 'restricted' Librarian. The current pattern is that these files are served from the launchpad.net domain. We use SafeStreamingOrRedirectFileAlias to serve user supplied files, and Streaming... to serve internally generated files.
However this has some issues: we cannot do inline rendering of user supplied files because they could attack launchpad cookies, perform AJAX and so on; its also non scalable and makes the appservers fragile due to downloading directly from the librarian.
OpenID and other cookie based solutions cannot help, because those cookies would be vulnerable to attack; we need something that partitions all user supplied content into one security context each.
The current plan is to use a separate domain using wildcard DNS, per contenthash (LFC object), on https, with a random token providing time limited access; tokens will be generated by the appservers even in readonly requests, and the librarian will check for tokens on all LFAs which have the restricted bit set.
https://code.edge.launchpad.net/~lifeless/launchpad/private-librarian/+merge/31020 details this approach.
|
The production Librarian runs on a non-launchpad.net domain. This means that if a HTML document or other content that can embed commands is served, the browser security model should stop it stealing authentication credentials.
We are now proxying some files via Launchpad - stuff served from the 'restricted' Librarian. The current pattern is that these files are served from the launchpad.net domain. We use SafeStreamingOrRedirectFileAlias to serve user supplied files, and Streaming... to serve internally generated files.
However this has some issues: we cannot do inline rendering of user supplied files because they could attack launchpad cookies, perform AJAX and so on; its also non scalable and makes the appservers fragile due to downloading directly from the librarian.
OpenID and other cookie based solutions cannot help, because those cookies would be vulnerable to attack; we need something that partitions all user supplied content into one security context each.
The current plan is to use a separate domain using wildcard DNS, per contenthash (LFC object), on https, with a random token providing time limited access; tokens will be generated by the appservers even in readonly requests, and the librarian will check for tokens on all LFAs which have the restricted bit set.
https://code.edge.launchpad.net/~lifeless/launchpad/private-librarian/+merge/31020 details this approach.
the code has landed; we're now rolling out a QA environment for this, which will be followed by enabling it.
|
|
| 2010-10-06 20:10:17 |
Robert Collins |
tags |
librarian qa-needstesting |
librarian qa-ok |
|
| 2010-11-16 14:43:04 |
Michael Bienia |
bug |
|
|
added subscriber Michael Bienia |
| 2010-11-17 13:28:17 |
Robert Collins |
launchpad-foundations: status |
Fix Committed |
Fix Released |
|
| 2010-12-08 11:47:33 |
Martin Pitt |
bug |
|
|
added subscriber Martin Pitt |
| 2012-08-09 23:42:01 |
William Grant |
removed subscriber Launchpad Security |
|
|
|
