[#LPP-384] Security Issue: Resources and Dataset allow to access any xml or image from the file system

OpenLaszlo

Security Issue: Resources and Dataset allow to access any xml or image from the file system

Created: 31/May/05 08:30 AM Updated: 09/Jan/08 06:45 PM

Component/s:

Compiler

Affects Version/s:

3.0

Fix Version/s:

3.1 (aka Denver)

Time Tracking:

Not Specified

File Attachments:

verify-code.zip (3 kb)

Severity:	Critical
Runtime:	N/A

Description

« Hide

While working on integrating Laszlo in XWiki (http://www.xwiki.org) and verifying that users would not be allowed to access the server by writing laszlo code I found the following security issue:

There is a security issue with the resource and src params in view and dataset.
It allows to access files from the file system by using .. to climb back the directories

For example the following code allowed me to access a file called ludo.jpg in the root directory of my system and the "port" information found in the server.xml file of my tomcat installation.

<canvas width="500" height="100">
   <view x="50" y="50" resource="../openlaszlo/../../../../../../ludo.jpg"/>
   <dataset name="mydata" src="../../../conf/server.xml" />
   <text datapath="mydata:/Server/@port" />
</canvas>

On your demo pages here:
http://www.laszlosystems.com/lps/laszlo-in-ten-minutes/

The following code put in one of the demo boxes and hiting update

<canvas>
    <view resource="../../../../../../../usr/share/pixmaps/printer.png"/>
</canvas>

Allowed to view an image from the share directory of your system.
It also allowed me to find out that you where running jetty and a linux system.

It seems to only work for images and xml files. I wasn't able to access pure text files, but I'm not a laszlo code specialist.

To fix this issue I thing the system should allow to constraint resources and external datasets compiles in the flash file to come from a specific directory.

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Oliver Steele - 06/Jun/05 02:47 PM

<include type="text" ...> could allow access to any text file.

The compiler shouldn't allow access to files outside the servlet directory, when it's invoked in response to an HTTP request.

[ Permlink | « Hide ]

Ludovic Dubost - 06/Jun/05 04:06 PM

So with the <include type="text" .. it is possible using the update form on
http://www.laszlosystems.com/lps/laszlo-in-ten-minutes/
to access any file of the file-system as long as you know the name of the file..

So the title of this bug should be rename from "any image or xml file" to "any file"..

[ Permlink | « Hide ]

Henry Minsky - 08/Jun/05 10:16 AM

There are a two cases we need to deal with:

1) people compiling passing arbitrary source code to be compiled on the server

For this case we need to either not allow this, or
restrict file access for <include> and <resource>
references to stop at the LPS servlet root directory, and also avoid going
into servlet-root/WEB-INF

2) At runtime, the LPS media and data proxy services which access files
directly (as opposed to proxying HTTP), should probably be disabled entirely,and only proxied HTTP requests should be allowed. Then the security issue is forwarded to the HTTP server policy. That would prevent you from getting the source for .jsp's for examples.

I'm working on a fix for 1) above, to restrict all compiler file access to
be underneath the servlet root.

For 2), I am leaning towards disabling all direct file access. I don't think people need to use it for performance gains now that we have SOLO apps.

[ Permlink | « Hide ]

Henry Minsky - 13/Jun/05 11:57 AM

oliver sez

No need to break sources --- it's cheap, in this case, not to. Let's make the runtime warn for strings that begin with file:, and the server treat them as http:. (The reason to make the server do the latter is so that the runtime only has to check for file: in the debug version, avoiding any size/speed overhead.)

[ Permlink | « Hide ]

P T Withington - 13/Jul/05 07:04 AM

Why aren't we just using the Tomcat security manager?

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/security-manager-howto.html

[ Permlink | « Hide ]

Henry Minsky - 10/Aug/05 06:24 AM

I tried to configure the Tomcat security, and failed.

What got me was that I tried to follow their instructions, and it was confusing.
They use the Java security classes, which seem to have one class per capability (like read file, write file, use network, etc), and it seemed like you
could either

1) allow all Java security options, which does us no good

2) pick the ones you need, and there were dozens, and I couldn't figure out
which subset to use/configureto make the LPS still work, yet somehow restrict access for
this case. And the syntax for specifying the parameters to each security class was not explained anywhere I could find either.

So I gave up on that. Not to say someone couldn't figure it out, but I wasn't getting anywhere very fast.

[ Permlink | « Hide ]

Henry Minsky - 10/Aug/05 03:34 PM

Oliver sez:

Oliver Steele <steele@laszlosystems.com> Thu, Jun 9, 2005 at 3:22 PM
To: Henry Q Minsky <henry.minsky@gmail.com>
Cc: platform-team@laszlosystems.com
Here's most of an implementation for this. These two files go in laszlo-explorer. The code displays an error and refuses to compile the program if a pathname begins with a .. or /, or has a colon in second position.

Remaining work:
- I hardcoded it to look for the xslt file on my machine. There's got to be some API for asking the servlet API which directory it lives in.
- Poke holes in it. I wonder if there's something you can do with "subdir/../.." to get out that this doesn't detect.
- Look at the doc examples. I think some of them include things that start with one level of .. on purpose.
- Maybe to address the preceding two cases, instead of rejecting an initial .., it should reject a pathname that contains any .. that isn't in the initial position.
- Add a copyright to verify.xsl.
- Write a list of cases to test for.
- I noticed there's a version-skewed version of the same code in laszlo-in-ten-minutes, which is used on the web site. At the least, the copies of content.jsp and editor.jsp in laszlo-in-ten-minutes should be changed to include ../laszlo-explorer, to eliminate that level of duplication. Maybe more files can be shared too.

Anyway, if someone can take this over, I think it will fix the originally reported bug (with extracting information from our web site, or a developer who's running the docs or OOBE). The 'file' bug is still open. I thought about making this same script reject "file:", but since you can request files programmatically this wouldn't plug much of that hole.

[see attachment]

[ Permlink | « Hide ]

Henry Minsky - 10/Aug/05 03:35 PM

code from Oliver

[ Permlink | « Hide ]

Henry Minsky - 11/Aug/05 11:32 AM

Changeset 31569 fixes this

[ Permlink | « Hide ]

Mark Davis - 14/Oct/05 03:08 PM

This was supposed to have been fixed in 3.0.2 but it looks like it is open in lps-dev right now. In my build environment, I can go to laszlo-explorer and use:
<canvas>
<view resource="../../../../Diagram1.png"/>
</canvas>

to access that file which is in my home directory.

[ Permlink | « Hide ]

Henry Minsky - 18/Oct/05 09:57 AM

Hmm, the filter that is supposed to check this in laszlo explorer is in verify.xsl only is looking at 'href' and 'src' attributes, I will add a filter for 'resource' as well.

[ Permlink | « Hide ]

P T Withington - 20/Oct/05 09:30 AM

That's the problem with 'Little Dutch Boy' security... you never know when another leak in the dike will spring up, but since that's our model, I guess this is all you can do.

[ Permlink | « Hide ]

Frisco Del Rosario - 21/Oct/05 09:32 AM

Filter for "resources" is working.

[ Permlink | « Hide ]

Jim Grandy - 25/Jun/06 04:41 PM

Final checkin on this was hminsky's 33835, on 10/20/2005.

[ Permlink | « Hide ]

Mamye Kratt - 26/Jun/06 12:47 PM

Thread from 6/25/06
Testing Results (Final for Sun) and [IMPORTANT] OpenLaszlo Security

I think we need to address ~~LPP-1270~~ as well here.

~~LPP-1270~~ OpenLaszlo Explorer and Laszlo in Ten Minutes allow users to save to file system

~~LPP-382~~ mentions this bug in passing as still open, and sure enough it is.

Note that as of 3.2, Laszlo in Ten Minutes is just a front end to Laszlo Explorer, so the comment about making sure to change BOTH copies of source.jsp is no longer operative (but may be important if we have to patch older deployments).
jim

On Jun 25, 2006, at 2:10 PM, Jim Grandy wrote:
[Dropping it@laszlosystems and Pablo.]
IMPORTANT: some of you have action items at the end of this message. Read all the way through.

OK, so the changes went in to lps-dev in two separate checkins, 31569 and 33835. There have been no changes to source.jsp or verify.xsl on that branch since then. I verified that the changes were propagated to the right branches. The file logs are given below.

Also, source.jsp and verify.xsl are identical in lps-dev and lps-3.3.

Finally, I have manually verified that the source.jsp file checked into lps-dev does contain the changes from 31569, and verify.xsl does contain the "*[@resource]" change from 33835.

So my conclusion is that the patches did make it into the appropriate branches, and from there into 3.1 and later, but that the patch does not fix the security problem being reported. There is a "*[@src]" rule in verify.xsl, but apparently it is not being triggered in this case -- or else the results of the xsl transform are not being properly used by source.jsp. There is also already a check for ".." in paths.

Amy, please spend some time on Monday working with IT to remove or disable all source.jsp files in deployed distros on the openlaszlo.org box, including www and labs and anything else.

Henry, please send your proposed change to source.jsp to platform-team for review and work with Mamye to test and verify it. Please describe why the version of verify.xsl from change 33835 does not fix the problem being reported. I'd like to have a proposed patch under review and test by noon EST on Monday.

Mamye, on Monday, reopen http://www.openlaszlo.org/jira/browse/LPP-384 with information from this thread. Then please patch a clean build of 3.3.1 with Henry's proposed change and test it against the reported exploit and the exploits described in ~~LPP-384~~. I'd like a report by EOD on Moday.

Tucker, you have been advocating for a more comprehensive solution to this security problem. Please spend some time on Monday and Tuesday putting together a recommendation for such a solution, one that does not require piecemeal patching of individual jsp scripts.

Everyone: I don't want experimentation to be done on openlaszlo.org. We will disable this feature on the public site until we have a tested, verified solution.

Here are the file logs:
jgrandyw$ p4 filelog //depot/lps-dev/laszlo-explorer/source.jsp
//depot/lps-dev/laszlo-explorer/source.jsp
... #4 change 31569 edit on 2005/08/11 by hminsky@domokun-lps-dev (text) 'Summary: fix for ~~LPP-384~~ - secu'
... ... branch into //depot/lps-3.2/laszlo-explorer/source.jsp#1
... ... branch into //depot/lps-dev-richtext/laszlo-explorer/source.jsp#1
... ... branch into //depot/lps-ginger/laszlo-explorer/source.jsp#1
... ... branch into //depot/lps-legals/laszlo-explorer/source.jsp#1
... ... branch into //depot/lps-pave/laszlo-explorer/source.jsp#3
... ... branch into //depot/lps-rapid/laszlo-explorer/source.jsp#1
... ... branch into //depot/lps-snippetunload/laszlo-explorer/source.jsp#1
... ... copy into //depot/lps/laszlo-explorer/source.jsp#12
... #3 change 25324 edit on 2005/03/25 by qa@carl-qa (text) 'Summary: JSP memory leak fix '
... ... branch into //depot/lps-pave/laszlo-explorer/source.jsp#1
... ... branch into //depot/lps-syl/laszlo-explorer/source.jsp#1
... ... copy into //depot/lps/laszlo-explorer/source.jsp#11
... #2 change 23539 edit on 2004/12/31 by yossie@yossie-home (text) 'add editable copyrights to all '
... ... copy into //depot/lps/laszlo-explorer/source.jsp#10
... #1 change 23200 branch on 2004/12/12 by mdavis@lyta (text) 'proper branch creation from lps'
... ... branch from //depot/lps/laszlo-explorer/source.jsp#9
jgrandyw$ p4 filelog //depot/lps-dev/laszlo-explorer/verify.xsl
//depot/lps-dev/laszlo-explorer/verify.xsl
... #2 change 33835 edit on 2005/10/20 by hminsky@domokun-lps-dev (text) 'Summary: fix lpp-384 security i'
... ... branch into //depot/lps-3.2/laszlo-explorer/verify.xsl#1
... ... copy into //depot/lps-ginger/laszlo-explorer/verify.xsl#2
... ... branch into //depot/lps-legals/laszlo-explorer/verify.xsl#1
... ... copy into //depot/lps-pave/laszlo-explorer/verify.xsl#2
... ... copy into //depot/lps-rapid/laszlo-explorer/verify.xsl#2
... ... branch into //depot/lps/laszlo-explorer/verify.xsl#1
... #1 change 31569 add on 2005/08/11 by hminsky@domokun-lps-dev (text) 'Summary: fix for ~~LPP-384~~ - secu'
... ... branch into //depot/lps-dev-richtext/laszlo-explorer/verify.xsl#1
... ... branch into //depot/lps-ginger/laszlo-explorer/verify.xsl#1
... ... branch into //depot/lps-pave/laszlo-explorer/verify.xsl#1
... ... branch into //depot/lps-rapid/laszlo-explorer/verify.xsl#1
... ... branch into //depot/lps-snippetunload/laszlo-explorer/verify.xsl#1

On Jun 25, 2006, at 1:13 PM, Amy Muntz wrote:
It just tried it on 3.1 and the problem still exists there. Some perforce spelunking might be in order at this point.
--- Amy
On Jun 25, 2006, at 3:55 PM, Amy Muntz wrote:

Test Results:

In a clean 3.3.1 download, I can use:
http://127.0.0.1:8080/lps-3.3.1/laszlo-explorer/source.jsp?&tag=The%20Canvas&action=explore&undefined=&title=Hello%20World&src=/laszlo-explorer/../../../../../../../../etc/passwd

and display the file. Note that you can't just use the tree to display directory contents, you must specify a file.

This is also broken in trunk.

REMEMBER - in 3.1, we checked in a fix to address accessing files using relative paths. See ~~LPP-384~~ (http://www.openlaszlo.org/jira/browse/LPP-384). Part of the fix includes a source.jsp file that has been attached. I think the next step is to track this in perforce and see where the changeset ended up (and in which branches).

(I'm going to try this in 3.1 right now to see if it was really fixed there).
-- Amy

On Jun 25, 2006, at 2:52 PM, Amy Muntz wrote:
This is what we're doing.

Right now, we are going to test and see if this is in our current installation so that we know exactly what we are dealing with.

Jim et al can discuss the next steps on Monday (once we have some of this data available).

Thanks,
Amy

On Jun 25, 2006, at 2:30 PM, Amy Muntz wrote:
Hi,
We HAVEN"T done anything yet.

We do have a patch for src.jsp - and Yossie could just patch those as a temporary fix for the security issue (which we have known about).

As for moving to a release greater than 2.1.2 -that's a bigger conversation!

Should Yossie proceed?
-- Amy

On Jun 25, 2006, at 2:24 PM, David Temkin wrote:
We have an ancient LPS deployed on the site. This actually has at least one other vulnerability that could be exploited using LZExplorer -- the old file:// URL "feature", which I think would allow you to retrieve any file, or at least any lps-readable file, from the file system even if the ".." problem is removed.

We need to upgrade this to the current release plus a patch to cover this problem. It's high time that we replaced the 2.1.2 build that's there now, for security and other reasons.

Mark, Jim -- can we discuss on Monday?

On Jun 25, 2006, at 5:10 AM, P T Withington wrote:
[Adding IT, platform-team]

We all know that the right fix to this is not to try to find all the holes in Apache/Tomcat/LPS and close them, right?. It's good to patch the known ones, but we'll never find the 'unknown unknowns'. :P

I wonder if we could run LPS in a [chroot jail](http://www.openbsd.org/faq/faq10.html#httpdchroot)? That would be one easy way to limit the damage that could be done.

On 2006-06-25, at 04:46 EDT, Henry Minsky wrote:
This new copy of source.jsp ought to fix this, it removes strings of two or
more '.' chars.

I would try to install this except I cannot ssh login to
sf.laszlosystems.com. It just hangs for me.

On 6/25/06, Don Hopkins <dhopkins@donhopkins.com> wrote:
Yes, there does seem to be a security hole:

http://www.openlaszlo.org/lps-latest/laszlo-explorer/source.jsp?&tag=The%20Canvas&action=explore&undefined=&title=Hello%20World&src=/laszlo-explorer/../../../../../../../../../etc/passwd
            -Don

-----Original Message-----
*From:* Don Hopkins [mailto:dhopkins@DonHopkins.com]
*Sent:* Saturday, June 24, 2006 10:50 PM
*To:* 'max@laszlosystems.com'; 'Sarah Allen'
*Subject:* FW: [IMPORTANT] root:[PASSWORD DELETED]@donhopkins.com

I thought maybe you'd like to know about a security hole in OpenLaszlo?

I just received some email written in French, from somebody who penetrated my system through OpenLaszlo, and was honest and polite enough to tell me about it!

I have redacted my root MySQL password in the subject line (good technique to get my attention through all the spam), and the contents of my
/etc/passwd that he sent me.
           -Don

Translation from French:

Hello, I found this bond on the site laszlo
http://www.donhopkins.com:8080/lps-3.0.2/laszlo-to explore and I remained an end of time to test capabilities of Laszlo. And I wanted to inform you that your configuration is not optimal. But on the other hand it leaves possible the intrusions. PS: Be more vigilant the next time, and excuses me for because I penetrated in your system in this way:) -

-----Original Message-----
*From:* ttys99 ttys99 [mailto:ttys99@gmail.com]
*Sent:* Saturday, June 24, 2006 6:35 PM
*To:* dhopkins@DonHopkins.com; ttys99@gmail.com
*Subject:* [IMPORTANT] root:[PASSWORD DELETED]@donhopkins.com

Salut,
     j'ai trouvé ce lien sur le site laszlo *
http://www.donhopkins.com:8080/lps-3.0.2/laszlo-explorer/* et j'ai resté
un bout de temps pour tester les capabilités de Laszlo. Et je voulais
t'informer que votre configuration n'est pas optimale. Mais par contre elle
laisse possible les intrusions.

PS : Soyez plus vigilant la prochaine fois, et excuse moi pour parce que
j'ai pénétré dans ton système de cette façon :)--
*Best Regards, *
*A Friend
*http://www.donhopkins.com:8080/lps-3.0.2/laszlo-explorer/
http://www.donhopkins.com:8080/lps-3.0.2/laszlo-explorer/source.jsp?&tag=The%20Canvas&action=explore&undefined=&title=Hello%20World&src=/laszlo-explorer/../../../../..///usr/local/src/drupal-4.6.3/default/settings.php
http://www.donhopkins.com:8080/lps-3.0.2/laszlo-explorer/source.jsp?&tag=The%20Canvas&action=explore&undefined=&title=Hello%20World&src=/laszlo-explorer/../../../../../usr/local/apache/conf/httpd.conf
http://www.donhopkins.com:8080/lps-3.0.2/laszlo-explorer/source.jsp?&tag=The%20Canvas&action=explore&undefined=&title=Hello%20World&src=/laszlo-explorer/../../../../..//etc/shadow

user error: Unknown column 's' in 'where clause'
query: SELECT DISTINCT(n.nid), n.sticky, n.title, n.created FROM dh_node
n INNER JOIN dh_node_access na ON na.nid = n.nid INNER JOIN dh_term_node
tn ON n.nid = tn.nid WHERE (na.grant_view = 1 AND CONCAT(na.realm, na.gid)
IN
('all0','node_privacy_byrole_role1','node_privacy_byrole_user0','simple_access0','term_access1'))
AND tn.tid IN (s) AND n.status = 1 ORDER BY n.sticky DESC, n.created DESC
LIMIT 0, 10 in /usr/local/src/drupal-4.6.3/includes/database.mysql.inc on
line 66.

[CONTENTS OF drupal config file DELETED]
[CONTENTS OF /etc/passwd DELETED]
--
Henry Minsky
Software Architect
hminsky@laszlosystems.com
<source.jsp>

[ Permlink | « Hide ]

Henry Minsky - 27/Jun/06 09:03 PM

change 1172 in lps-legals patches source.jsp to strip leading slash and .. sequences from the src pathname query

[ Permlink | « Hide ]

Henry Minsky - 10/Jul/06 01:28 PM

There are two separate issues going on here:

1) The issue of the source.jsp placing a temporary file into the filesystem with a path based on the "src" query parameter

2) The issue of the LPS compiler pulling in compile-time media and data (and maybe textual lzx source via <include>)
and compiling that data into an app. (e.g., <view x="50" y="50" resource="../openlaszlo/../../../../../../ludo.jpg"/> )

Issue 1) is easy to fix by checking the file path and making sure it is prefixed by the app working directory

Issue 2) could be addressed by having a flag in CompilationEnvironment that says
what a valid prefix is for files that are included at compile time, I guess.

[ Permlink | « Hide ]

payne - 09/Jan/08 06:45 PM