Frostbite Falls

News you can use about Windchill PDMLink and ProjectLink
Slightly 7.0 centric.

Monday, June 13, 2005

PTC Tech Support Considered Misleading

I wasn't planning on slagging on PTC for my first two posts, but these are the pressing issues of the day. In trying to configure Windchill for use behind a reverse proxy, there are two TPIs that talk about this configuration. They are 125639 and 128629. All fairly straight forward, you would think.

Ahh...but then you read the TPIs. They in fact tell you to do two diametrically opposite things for wt.httpgw.codebase. One says to fill in the reverse-proxy name, the other says to fill in application server address.

Actually, as I proof this post, it looks like 125639 has disappeared from the PTC website. I had a tech support call open on this, and it looks like it may have helped. At least in my configuation, it's still not working. And I want to know what wt.webapp.name does.

Monday, June 06, 2005

PTC Training Considered Harmful

Not entirely harmful, but be careful. I'm looking at "Windchill 7.0 Workflow Administration," and there is a gaping security hole in one of the examples given. (Plus a typo, but that's free for the asking). On page 6-39, it describes the Application Robot, which allows you to run arbitrary system commands within a Windchill workflow.

The example given has as a command "java MessageDisplay {name} {date} {message}", where the names within thew curly brackets (e.g. {name}) are workflow variables. These implication of the instructions is that you can have a user type in values of these variables in a earlier task, then use the values as parameters in the application robot.

This is a bad idea, especially on Windchill instances that run on Unix platforms. Using any unvalidated user input opens up the possibility of an injection attack. A detailed example in relation to SQL can be found here. Although the SQL example is fairly bad, the PTC example is possibly worse. On a unix machine, an attacker could type in `cat $WT_HOME/codebase/wt.properties` into the message field. The attacker would then get the contents of the wt.properties file displayed by MessageDisplay. Not too good, since the username and password for the database is stored in plain text in wt.properties.

Always, Always, Always validate user input that is used to do anything meaningful. Especially if you have ITAR data on the system.