3

The control + j feature within PeopleSoft outputs a list of potentially interesting data for a potential attacker. The feature is generally used to aid in debugging. Here is a the [censored] output from a control + j:

enter image description here

Is it a security risk to have control + j functionality enabled in a production (live/public) instance of PeopleSoft? I imagine it is a risk (albeit perhaps small) because it simply saves time for the potential attacker in giving them the specific platform knowledge to go lookup known attacks for that platform flavour.

Is my assessment correct? What other risks (if any) does it impose?

5
  • 1
    In general, all debugging info should be restricted. That's why even 404 error pages should be customized so that only allowed information is disclosed.
    – schroeder
    Nov 5, 2014 at 16:00
  • 1
    That's what I say but the counter-argument is always that this particular tools is useful for the helpdesk to track down problems... Nov 5, 2014 at 16:09
  • Then the decision-maker needs to weigh the customer-service benefits with the info disclosure risks. Is there anything in the debug info that cannot be gleaned using other methods? For instance, can I get the platform info any other way in order to search for platform-specific vulnerabilities?
    – schroeder
    Nov 5, 2014 at 16:11
  • I would submit that all of this information can be ascertained elsewhere but it would require far more work than a simple two button click... Nov 5, 2014 at 16:13
  • Then, if true, from a data classification perspective, the data is already public.
    – schroeder
    Nov 5, 2014 at 16:35

1 Answer 1

2

I would say a lot depends on if the users are remote, or are on the local machine. I would disable the feature if you do not need it.

Local user / attacker:

If the users are local, an attacker can find out most (but not all) of this information fairly easily, although this report would certainly make it easier for the attacker. Even locally, there are a couple pieces of data that would probably be hard to obtain by other methods that could be useful to attackers.

  • I see component buffer size as being troublesome because it could aid in buffer overflow attacks.
  • Depending on the implementation of the database, database name or possibly component could aid in a SQL injection attack as well (if PeopleSoft is vulnerable to this, which I do not know). Most of the other information can aid in an attack, but is generally available at the local machine anyway.

Remote user / attacker:

If the users are remote, this report is far more problematic. It reveals many details that would be useful to attackers, which would be harder for them to obtain through other means. For example, the OS, browser, service pack, etc... would let the attacker know what they are attacking and if it is out of date (so they know what vulnerabilities there are).

I would highly recommend disabling this feature if you do not need it and there are remote users.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .