SSL and Weblogic

As previously mentioned, I was doing an analysis of how PeopleSoft and Weblogic utilize SSL which was spawned by the announcement of POODLE.  I’m going to review my findings for Weblogic 10.3.6.x and then duplicate the analysis to see if anything is changed with Weblogic 12.1.2.  Weblogic 10.3.6.x is supported for any PeopleTools 8.50 – 8.53 installations.  If you are on an older release of Weblogic 10.3 you should upgrade your Weblogic. Continue reading

PeopleSoft and POODLE

POODLE has been a fairly common topic with security teams recently since Google announced the vulnerability.

There is plenty of reading available on the POODLE attack so I’m not going to go into too much detail but I’ll give a short description.  POODLE is a man-in-the-middle attack which uses an attackers ability to force the protocol of the server/client communication to fall back.  When the attacker can force the downgrade of the protocol to SSLv3 they can attack the weaknesses of that protocol.  SSLv3 has been around for a really long time, since 1996, and has been superseded by multiple versions of TLSv1.x.  TLSv1.2 is the latest version available and TLSv1.3 is currently in draft status.  As these new TLS versions were released they were implemented in new servers and applications, however for interoperability all the old protocols were also left active.

So are you vulnerable? As a PeopleSoft Admin/User/Developer do you need to worry about this?  Well, that depends.  Continue reading

PeopleSoft Timeout Problems in 8.50 – 8.52

There have been several PeopleSoft Timeout problems that have impacted various levels of 8.50, 8.51, and 8.52.  Indications are all these problems are fixed now.  According to Oracle, the code has also been fixed in 8.50.25, 8.51.17, 8.52.07, and 8.53.  I’m sure a new problem will pop up at some point though.

The first problem which I consider the most dangerous, is that the timeout warning process breaks down and causes a users browser to repeatedly request the timeout warning pop-up page.  It looks like this particular problem impacts 8.50.22, 8.50.23, and 8.50.24.  It looks like it also impacts 8.51.12 – 8.51.16 and 8.52.00 –  8.52.06.  I don’t have the 8.51 or 8.52 versions running, however looking at the code delivered in the 8.51.16 and 8.52.06 patches, the problem code does exist.  I know 8.52.07 does not have the bad code because I do have access to an environment at that level.  This was actually put in as a fix for another problem, which I’ll mention later.  It was put into 8.50.22, 8.51.12, and 8.52.00.

Users may have their PC’s hang as the browser takes CPU to 100% requesting the timeout warning page. Or if you have access logging turned on and you review the web server access log you will see hundreds to thousands of requests for the warning page from a single IP repeatedly in quick succession.  In some cases this can cause the web server to crash.  In other cases I’ve heard of it maxing out jolt connections on the app server.  Oracle has a work around posted [ID 1405219.1].

It looks like they used the wrong JavaScript method and instead of using setTimeout() used setInterval().  What then occurs is the user will have a small amount of time left after the original setTimeout() was called. There is an if statement in the code that “if (current time – last access time) is less than (the warning time – a small adjustment)”  then call setInterval() for the pop-up with the interval being the remaining time.  This is the fix they put in (the if statement was there earlier without the setInterval() call).  For some reason certain systems are having time left over and entering this If condition, but in older 8.50 code the loop simply returned thus exiting without displaying the time out window.  Well setInterval() runs it’s parameter repeatedly at the specified interval.  In order to just delay the pop-up the remaining amount of time it should be setTimeout().  The work around directs you to correct this.

If you are experiencing this first problem.  After updating the code on the HTML object PT_SAVEWARNINGSCRIPT you may need to force users to clear their browser cache.  I saw this JavaScript being cached on the browser and not being reloaded even though the web servers had been restarted and their own cache cleared.  Since there was 4000 users at the site, they changed the cache directory in the web profile to force a new URL which did the trick.

Another problem is that time outs across windows/tabs are not synched.  This one I think has existed for a long time actually. Oracle indicates that there was a bug in 8.4x that they did not fix which allowed users to not be timed out of idle windows but since it was a bug, it was fixed in the 8.50 release.  I’m not sure what 8.4x releases that bug impacted.  Good news is it’s fixed moving forward.  Oracle says this about the behavior.

In PT8.4, if end user is active in one browser window, but lets the other window remain idle and timeout, the end user could continue in active window. This was a bug: 11558697 in PT8.4 and incorrect behavior. Many customers prefer the incorrect behavior in PT8.4; however, that behavior was a bug. The timeout behavior in PT8.50 is correct and development will not revert back to PT8.4 timeout behavior.

So with 8.50 users start experiencing timeout behavior they may not have seen before.  If your users perform a function that commonly spawns new windows this may impact them.  One particular scenario would be they simply missed the timeout warning pop-up and didn’t acknowledge it, they would now be timed out even if they were active in another window.  This is corrected now in the newer releases indicated above.  They have rewritten the JavaScript to utilize the value of PS_TOKENEXPIRE, which provides a singular Last Access time, across the browsing session.  A nice change if you ask me.  In fact, since PS_TOKENEXPIRE is shared across all SSO shared environments, that actually allows Portal and Content databases to timeout together, another nice addition.  I saw a reference to PeopleBooks 8.53 being updated to specify this, however I wasn’t able to find it yet.

Another more complicated scenario of this problem allows users to be timed out even after clicking OK on the timeout warning window.  This probably doesn’t happen all that often but I heard from a previous co-worker that he has had users impacted by this.  If you open three windows pretty close to one another and remain only active in the third one and leave the visualother two open, you could fall prey to this.  Here’s the details.  Window A gets opened with it’s own timeout. 10 seconds later the user then opens window B, also with it’s own timeout.  In window B they do something to open window C. They continue to work in window C.  The warning will be displayed based on inactivity for window A.  If the user does not acknowledge the timeout by the time window B gets to it’s warning time (10 seconds after window A) window B will initiate a new warning.  However, the warning from window B won’t create a new window, it will update the existing pop-up from window A.  Now we have a problem.  Two windows with separate timers will timeout in a few minutes but there is only one pop-up window.  My testing with IE indicates the JavaScript will actually reset the timer in window A however the browser will make a GET call for window B.  The GET call doesn’t impact the JavaScript timer but it will keep the web server session alive (but your already active in the other window so we are fine there).  What then happens is window B will time out shortly leaving the user wondering what just happened?  They clicked OK on the warning but still got timed out.  As you can see, I tried to present a visual depiction of this process.  I’m not very good with those tools so I hope you can enjoy a laugh at my art work.

I’ve also seen reference to some other problems regarding where the setuptimeout() function is called in the JavaScript.  But I don’t have too many details on that one, it sounds like they were calling setuptimeout() from code associated with key presses.  This did not necessarily make a request to the server.  So you could be typing up your performance review for 2 hours and the window would not time out.  But once you went to save the review, your session had already timed out, and all was gone.  I think even I have been hit by that one before.  This also has been fixed with the new code, you’ll be warned about timing out now to avoid your web server session from vanishing.  This fix was also supposed to go in with the 8.51.17 / 8.50.25 updates.

Why you should have different local node passwords

I was doing an assessment of a Peoplesoft installation recently when I noticed that the node passwords were the same across all environments of the same application type. While this might not seem like it is a big deal, it can open up a production environment to unauthorized access or accidental data entry. If this sounds like your environment perhaps some of your developers or users may have already realized that this allows them to access production with out a password from a non production environment, especially if they use bookmarks or direct URLs.

The problem here is related to a mechanism of Peoplesoft’s authentication. The PS_TOKEN cookie which is used for authentication is created from among other things the issuing systems default local node and password. If this data is the same across say, all your HCM environments, then a PS_TOKEN created in a development environment can also be valid in the corresponding production environment.

My recommendation is simple enough, force the node passwords to be different for every database in your install via your refresh script or process. This will ensure the PS_TOKEN is not valid across multiple instances of the same application and prevent this rather undesirable “feature” that I know several developers have enjoyed and even relied on in the past.