Patching Order

[Erik_Fridell_2]

I would like to know if it matters as to the order that hotfixes are applied to the media server. I patched our media server to protect against the most recent exploit and after I applied the security rollup, decided to apply the SP1 compatibility patch and the Exchange hang patch. Now the version number on my remote agents isn't correct for hotfix 52 and I want to know if I'm still going to be vulnerable against the most recent exploit! Any information would be greatly appreciated!!!

[Ken_Putnam]

For HotFixes only, apply in HotFix number order.

If an SP is involved, apply in Date/Time order. An SP should roll up all previous Hotfixes, and a new HotFix should indicate if an SP is required.

[Erik_Fridell_2]

I decided to do a bit of testing while waiting for a response and found the following. I reapplied hotfix 52 to the media server and reinstalled the agent on one of our servers. When checking the remote agent version number and the files that were modified, I found that there was no change. Unfortunately, the remote agent still does not seem to be in line with the correct version and files for hotfix 52, which is pretty scary. This security hole is already being exploited by metasploit and I need to be 100% sure that we're patched against this. Why isn't hotfix 52 working for me even though Veritas is telling me that it's installed?!?!

[Ken_Putnam]

Did you push/reinstall over the top of the existing RAWS, or did you uninstall on the remote server and then push again?

[Erik_Fridell_2]

First I reinstalled the hotfix on the media server. Then, from the console of the server with the remote agent, mapped a drive to the RANT32 install directory on the media server, uninstalled the agent, rebooted the server, and then reinstalled the agent via the drive mapping (as per the agent uninstall/reinstall directions located in the Veritas administration guide).

[Ken_Putnam]

AFAIK, that should have worked.

Guess you'll have to wait for a Veritas tech to answer this one.

[Erik_Fridell_2]

Sigh, that's what I was afraid of. Thanks for your help none the less! Okay Veritas techs, this one's for you!!!

[padmaja_rajopad]

Hi,

Service Pack 2 is a prerequisite for the security rollup for 9.1

This is mentioned explicitly in the technote

9.1 4691 Hotfix 52 - Backup Exec for Windows Servers May 2005 Security Rollup *Requires Backup Exec 9.1 4691 Service Pack 2

http://support.veritas.com/docs/275909 .

The version of the beremote.exe on the remote server should be 9.1.4691.49 after installation of the above patch.

Whats the version of beremote.exe on the remote server?

Can you check whether Service Pack 2 is already installed on the system?

If not please install Service Pack 2 and then install the Security Rollup.

The SP1 compatibility patch and the Exchange hang patch both need Service Pack 2 as well......!


NOTE : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to the ‘answered questions’ pool.

[George_Steinbre]

Hello,

We also are having this problem. We DID install service Pack 2 first. What I have noticed is the the RAWS.MSP in our RANT32 is dated 3/1/2005. The RAWS.MSP in our RANT64 is dated 6/3/2005. Our version of beremote.exe on the remote servers was upgraded to 9.1.4691.35 which is what comes with SP2. Our version of beremote.exe on the media server is 9.1.4691.49 which is the version this patch is suppose to upgrade it to.

The hotfix 52 does not seem to update our agent installation RANT32 directory with the new version of RAWS.MSP

[Deepali_Badave]

Hello,

we want to know if the solution provided has helped you in getting resolve your problem?

Please update us on this issue.

NOTE : If we do not receive your reply within two business days, this post would be marked assumed answered and would be moved to answered questions pool.

[George_Steinbre]

The solution above did not fix our issue. I even when as far as to reinstall service pack 2, and then reinstalled the hotfix again, with the same results.

[Craig_Henning]

I work with George. We are still waiting for a solution here. Your procedure is not working and the remote agents are still showing the wrong version.

Please do not let this thread die without an answer.

[Erik_Fridell_2]

I started this thread a while ago and ended up having to come up with a solution on my own since Veritas tech support proved to be pretty much worthless. Yay outsourcing to India. Way to save a couple of bucks there Veritas (or Symantec now maybe?). Since I couldn't sit around and wait for an answer while my boxes were getting hacked, I ended up uninstalling all of the agents that I had deployed, uninstalling and reinstalling the media server, patching my media server in date order on the patches, and then reinstalling all of my agents. This resulted in the correct version of the agent being deployed to all of the servers that I need to back up. If you want to try this method, the directions for uninstalling and reinstalling your media server without losing job history or media information can be found here:

http://seer.support.veritas.com/docs/260054.htm

About half way through this process, another sysadmin on campus from a different IT group came up with a quick and dirty way to force your agents to update, but since I was already past the point of no return on my uninstall-reinstall, it didn't really serve a purpose for me and I didn't have a chance to try it myself. If you'd like to try that method instead, here are the directions:

1. Start > Run , then browse via UNC to the \veritas\agents\RANT32 folder on your Backup Exec media server
2. Right-click on the RAWS.msp file dated 6/3/2005 and select 'Apply'
3. Locate C:\Program Files\VERITAS\Backup Exec\RANT\beremote.exe on the remote server
4. Right-click on beremote.exe, select Properties and click on the 'versions' tab (version should now read 9.1.4691.49)

So there it is. All I have to say is get this done as soon as possible. I was lucky enough to have my servers protected by network firewalls, so I didn't see any of my machines get compromised, but I did a test hack on our development server with Metasploit and had shell access in about two seconds, while standing on my head, backwards, with my eyes close, up hills both ways in the snow. It's that easy to hack a box with this vulnerability. Best of luck, and I hope this helps!

Erik

[Renuka_-]

Hello Eric,

Thank you for that update, It will certainly help the forum users experiencing the same problem.

- Regards.

[Craig_Henning]

Slick. Good job Eric and thank you for sharing your solution with us. I have some work to do now...
:)

Craig

[Craig_Henning]

I tried your solution Erik and it does not work for one reason, the RAWS.msp file in the directory is not the version it should be. The media server does have the right version of beremote but the installer for 52 did not update the RANT32 folder in that path.
I can't believe that Veritas/Symantec would put out a product that has such a huge vulnerability and then run like dogs when their patches do not work. Unfortunately my manager let our support contract lapse but under these circumstances Symantec should provide support for free. They have opened a door on our servers to every hacker on the planet yet they hold our their hands asking for money to provide an answer. That is just criminal as far as I am concerned.
I doubt we will be running their products much longer if they are willing to sacrifice my security over money when we paid them tens of thousands of dollars to buy the product to begin with.
If I don't see an answer posted here by Tech Support (one that works) NTL COB Monday 8 Aug. then I am going to cancel my request to order Veritas 10 and switch to something else entirely. Seeing as how I am backing up almost 100 servers I'd hope they have a better response than they have provided so far...

[Jared_Shields]

We are suffering the same fate as the others in this thread. We also installed all the patches in the proper order, but the hotfix 52 did not get applied to the RANT32 directory for some reason. It appears that everything else on the media server was updated properly, so we're wondering if Veritas could just provide the updated RAWS.msp file to place in the Remote Agent directory... or provide a working hotfix.

[Jared_Shields]

I just discovered: VERITAS Backup Exec (tm) 9.1 for Windows Servers revision 4691 - Service Pack 3
at http://seer.support.veritas.com/docs/278302.htm which lists "ETrack: 41041 RAWS push install is not working properly"

We're going to give this update a try tonight, our fingers are crossed.

[Amruta_Bhide]

Hello,
Hello Jared,
We will wait for your Update then.

Craig,
Have you tried installing the SP 3?

******************************************************************
*****************************************************************

Note : If we do not receive your reply within two business days, this post would be marked ‘assumed answered’ and would be moved to ‘answered questions’ pool.


Thanks.

[disable_mutantc]

Hi,

We are using Enterpise Vault 2007 SP2 with Exchange 2007 SP1

We have applied Rollup 8 for Exchange 2007 SP1.

Have just notice that client cannot access there archive email from OWA (outlook web access).

These are the errors we are experienicing in the event log.

First error message

-
The error c0041801 occurred whilst calling the method CArchivingAgentQueue::RestoreItem()

For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp
-

Second error message

-
Client request refused due to insufficient privileges, user Server\EV-Anonymous attempted to access the Archive Folder:

Archive name: Joe Bloggs
Archive folder path: \iscct
Vault Id: 15320B79841A448408A8402F1A498C0DE1110000serverexevsit01.qut.edu.au but does not have permission(s) (Read).
A frequent cause of this Warning is a user attempting an operation on a forwarded, moved, or copied shortcut to a Vault for which they do not have the required permission(s).

For more information, see Help and Support Center at
-

Does anybody have a fix for this problem.

I was planning to re-installed the OWA extensions hoping that will fix the issue.

Any help would be greatly appreicated :)

Regards

Jaime