Skip to Main Content

Analytics Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Risk of alert CVE-2019-2725 for Hyperion

User_54AZBMay 9 2019 — edited Jul 15 2019

I'd like to ask for the risk and vulnerability for application Hyperion. Our customers has Hyperion application (also with weblogic) on the internal network, so outside access is not possible. If I understand it correctly, CVE-2019-2725 would be a problem if the weblogic was in a DMZ (demilitarized zone) or if a potential attacker got into a customer network

Could you please advise me?

Thank you

Maroš

This post has been answered by iArchSolutions-Joe on Jul 11 2019
Jump to Answer

Comments

unknown-951199

>Anyone has any ideas?

a problem exists

content deleted

How do I ask a question on the forums?

https://forums.oracle.com/forums/thread.jspa?threadID=2174552#9360002

Ivica Arsov

Hi,

You need to provide more detail information ... from this I see shutdown initiated by user.

Ivica

jgarry

What platform are you on?  Do you have a cron doing a bounce for backups?  Does it happen at the same time?  Are you on a VM?

BPeaslandDBA

Occasionally, it automatically shuts itself down

Shutting down instance (immediate)

The two statements above are in direct opposition to itself. The database will not automatically shut itself down and the second line shows a SHUTDOWN IMMEDIATE was explicitly requested. Now maybe you didn't do the requesting, but someone or better yet...something made the request. Check for scheduled batch jobs that are performing a cold backup...or one that the previous DBA implemented to perform a regular restart "just to clear things up".

Cheers,

Brian

Aman....

Like other members have mentioned, without an explicit attempt, it's not possible. So check for any scheduled jobs, review the auditing logs and ask around if someone is having itchy fingers.

Aman....

Harmandeep Singh

Just two cents, From the timings of shutdown and startup, as others said, look at various logs and cron jobs

Regards,

Harman

tvCa-Oracle

There's different ways to find out, one is to start changing passwords. Of course, using the pre-designed method.

It could be an external system, reaching out to your server.

Could be a lot, really. But just check Crontab

Vsevolod Afanassiev

Is it running in noarchive,log mode? May be it gets shut down for cold backup?

Is there a time gap between shutdown and startup?

What's about the server where the database is running? Does it stay up or it also gets restarted? On UNIX user "uptime" to determine when a server was restarted.

User726571-Oracle

Hi All,

Thank you very much for all of the replies. My sincere apologies for not fully complying with all forum rules and etiquettes.

This is a QE automatic  environment where the problem is seen occasionally (not always).

It cannot be reproduced in development or other manually driven QE environment.

Here is the information on the automatic process and its environment.

* It accepts a job request with all necessary parameters from a user

* it arbitrarily allocates a host machine - a Linux (OLE5/6) image, from a pool of hosts

* It installs the DB (oracle 11.2.0.1.0) on the that host

* It installs the applications/products on the same host

* It runs all kinds of test scripts that include some selenium tests for UI implemented using Oracle ADF

* It occasionally fails only on selenium tests

* After completion of the job, it creates a job report on partially or fully successful tests.

* The host image is available for a few hours after the job completion notification

* Users have access to DB log files and application log files for a few hours.

* The host image is then retuned to the pool of hosts and thereafter no further access to the host is possible.

Regards,

-ab

jgarry

Well, in the absence of other errors, the likelihood is either there is something wrong with the script, or somehow it is getting run twice without actually creating a new VM (I'm guessing however it is created assumes it is not in use), or you have some backup routine for the VM that shuts down the db in conflict with the test, or something else is wrong.

I have seen situations where VMs run out of resources and restart, leaving old ones hanging, but that depends on the VM.

1 - 10