Firewall plus

A firewall is necessary for any system, but is not sufficient to solve all security issues or protect sensitive data against what is accurately named the "inside job." Anyone gaining access to a UNIX shell or Windows desktop with client access to a Progress-based ERP can virtually get anything he/she wants via the Procedure Editor if there is no security on the database.

Now you may breathe a sigh of relief thinking "Oh, our security is set up," but I'm willing to bet your wrong. Based on my experience very few folks have actually set up security on their databases themselves, instead they've been relying on their application security to protect data. But if I am able to take one clause out of the Progress client script, the "-p" startup program parameter clause, then I can go straight to the procedure editor and have my way with their data unless something else stops me, i. e., Progress database security.

Path-based dlopen issue

Here's another one that exploits the sticky bit. The removal of the sticky bit, which they recommend, is an interesting idea, but I can't see how that wouldn't disable the entire system... never tried it though...

I got to this link via another link from a security blog, this one talks about using dbagent. Funny - they state "A valid workaround to nearly any Progress security hole is to remove the suid bit from all binaries." So....the big question, does it work??

Progress suid security problem

The SUID (Set User ID) issue seems to be one which has been detected in the past. Here's a page explaining it.

Details:

• UNIX. There are lots of posts on the dangers of SUID/SGID.
• Latest versions of Progress 8.3 and Progress 9.1.
• Possible solution which they provide is to remove the suid bit from the binary but that that may compromise normal operation. My guess is that this would definitely blow functionality because the whole reason the sticky bit is set is to allow users to mod files via the database system.