Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Log4j - Log4Shell Critical 10/10 vulnerbility 11
- Thread starter jallen2020
- Start date
- Status
I still never had a 'corrupted' message.
But it may help to stop One-X Portal service before uploading files.
I had best results when doing it in this order:
- upload all the files, wail a moment
- update Webcontrol. Need to login again.
- Ignore if it still show as being on the old version.
- 'update all' with the respective button in one go.
- reboot, check if all good.
But it may help to stop One-X Portal service before uploading files.
I had best results when doing it in this order:
- upload all the files, wail a moment
- update Webcontrol. Need to login again.
- Ignore if it still show as being on the old version.
- 'update all' with the respective button in one go.
- reboot, check if all good.
Webcontrol just fail to update at our systems.
We do as you told. Then when we update webcontrol, it gives us a message 'webcontrol not running' Then we are not able to logon again.
after restart the webcontrol via CLI, it's just on the 'old' version and we're back where we started.
We do as you told. Then when we update webcontrol, it gives us a message 'webcontrol not running' Then we are not able to logon again.
after restart the webcontrol via CLI, it's just on the 'old' version and we're back where we started.
Did you follow this @Okkie?
Deploying critical patch on Server Edition and Application Server
Please follow the exact sequence mentioned below.
Login to Web Control Panel.
Navigate to the ‘Settings->General’ and upload the RPM using ‘Applications’ options.
Navigate to the ‘Updates’ tab.
Apply the patch to ‘webcontrol’ service using the RPM provided for Sever Edition.
Apply the patch to ‘one-X Portal’ service.
Apply the patch to ‘Web Collaboration’ service.
Apply the patch to ‘WebRTC Gateway’ service.
Apply the patch to ‘Media Manager’ service.
Verify the versions in services tab of Web Control Panel match the artifact versions.
Deploying critical patch on Server Edition and Application Server
Please follow the exact sequence mentioned below.
Login to Web Control Panel.
Navigate to the ‘Settings->General’ and upload the RPM using ‘Applications’ options.
Navigate to the ‘Updates’ tab.
Apply the patch to ‘webcontrol’ service using the RPM provided for Sever Edition.
Apply the patch to ‘one-X Portal’ service.
Apply the patch to ‘Web Collaboration’ service.
Apply the patch to ‘WebRTC Gateway’ service.
Apply the patch to ‘Media Manager’ service.
Verify the versions in services tab of Web Control Panel match the artifact versions.
Groundhog Day
Log4j 2.16 is no more good enough. We need 2.17
Can we start from scratch again?
Log4j 2.16 is no more good enough. We need 2.17
Can we start from scratch again?
We will probably. I’ve seen it over the weekend.
I think the next SBC Patch will be there soon
IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN
I think the next SBC Patch will be there soon
IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN
I have patched our Lab IPOSE as well as a customer now, I updated the RPMs in no particular order (I didn't read about the specific order), and while I got some errors about corrupted RPMs I just kept uploading them again and trying again, eventually it went through and updated all the packages.
So my advice for anyone getting 'corrupted rpm' messages, just keep re-uploading and trying again. I used Chrome.
Cheers,
BFG9K
Avaya IPO/ACCS Technician
Melbourne, Australia
So my advice for anyone getting 'corrupted rpm' messages, just keep re-uploading and trying again. I used Chrome.
Cheers,
BFG9K
Avaya IPO/ACCS Technician
Melbourne, Australia
avaya updated the patch files
UPDATED TO Patch v2 appears to be the same files. but now includes UC Module.
IPO11.0.4.6-CP20122021-Log4j2.zip , 11.0.x same MD5 on the files
IPO11.1.2-CP20122021-Log4j2.zip , 11.1.x now includes UC Module
UPDATED TO Patch v2 appears to be the same files. but now includes UC Module.
IPO11.0.4.6-CP20122021-Log4j2.zip , 11.0.x same MD5 on the files
IPO11.1.2-CP20122021-Log4j2.zip , 11.1.x now includes UC Module
The download address for the 1.2 is wrong
Avaya buggered it up, the download is not IPO00009417 but IPO00009415 if you search for it
the link is changed in the last digit to 5 from 7
Addendum:
That is the old download so maybe they didn't release the new one yet or pulled it because it makes the system blow smoke or something.
Joe
FHandw, ACSS, ACIS
"Dew knot truss yore Spell Cheque
Avaya buggered it up, the download is not IPO00009417 but IPO00009415 if you search for it
the link is changed in the last digit to 5 from 7
Addendum:
That is the old download so maybe they didn't release the new one yet or pulled it because it makes the system blow smoke or something.
Joe
FHandw, ACSS, ACIS
"Dew knot truss yore Spell Cheque
I will apologize in advance of this question but am a bit confused as to the files that are contained in the 11.1.2 patch folder.
The RPM files are self explanatory and are loaded using web page and application button.
But there appears to be 2 checksum files that I am an not sure what to do with them and nothing in release notes that I can find.
AvayaOneXdesktopclients_11.1.2001.90.exe.SHA256
onexportal-11.1.2001-90.RPM.SHA256
There is another file onexportal-11.1.2001-90.RPM which I assume is the one to load.
But there is no other AvayaOneXdesktopclients_11.1.2001.90.exe
So I am confused as to which files need to be uploaded.
Your insight would be appreciated.
The RPM files are self explanatory and are loaded using web page and application button.
But there appears to be 2 checksum files that I am an not sure what to do with them and nothing in release notes that I can find.
AvayaOneXdesktopclients_11.1.2001.90.exe.SHA256
onexportal-11.1.2001-90.RPM.SHA256
There is another file onexportal-11.1.2001-90.RPM which I assume is the one to load.
But there is no other AvayaOneXdesktopclients_11.1.2001.90.exe
So I am confused as to which files need to be uploaded.
Your insight would be appreciated.
-
1
- #52
-
1
- #54
The SHA256 files are literally just SHA256 sums for the files, if you open them in notepad you will get a string, it should match the SHA256 hash for each of the files.
They're hashfiles, and you should be comparing them to the file hashes to make sure they haven't been corrupted.
Cheers,
BFG9K
Avaya IPO/ACCS Technician
Melbourne, Australia
They're hashfiles, and you should be comparing them to the file hashes to make sure they haven't been corrupted.
Cheers,
BFG9K
Avaya IPO/ACCS Technician
Melbourne, Australia
Some references:
BAZINGA!
I'm not insane, my mother had me tested!
BAZINGA!
I'm not insane, my mother had me tested!
-
1
- #57
To answer my comment above about 'GroGroundhog Day'.
There are several options to fix the initial problem:
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
[ul]
[li]Java 8 (or later) users should upgrade to release 2.16.0 (now 2.17).[/li]
[li]Java 7 user should upgrade to release 2.12.2 (now 2.12.3).[/li]
[li]Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class[/li]
[/ul]
Avaya did upgrade to 2.16 but also remove the JndiLookup class.
If I understand correctly, they are not exposed to CVE-2021-45105 because of this.
In addition, the issue which is solved by 2.17 is 'only' a DOS (Denial of Service) attack. The initial problem was a RCE (Remote Code Execution).
There are several options to fix the initial problem:
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
[ul]
[li]Java 8 (or later) users should upgrade to release 2.16.0 (now 2.17).[/li]
[li]Java 7 user should upgrade to release 2.12.2 (now 2.12.3).[/li]
[li]Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class[/li]
[/ul]
Avaya did upgrade to 2.16 but also remove the JndiLookup class.
If I understand correctly, they are not exposed to CVE-2021-45105 because of this.
In addition, the issue which is solved by 2.17 is 'only' a DOS (Denial of Service) attack. The initial problem was a RCE (Remote Code Execution).
@BFG9K
Right, they just hold the checksum.
But is this file only provided to us for verifying the download?
They could also just have this info on the download page. I do check large downloads when this information is available.
Or is it also used by the system itself?
Anyway, why are only some of them available and not all?
I don't know. However, it only takes a second to upload them, so unless someone explains it, I will upload them.![[wink]](/data/assets/smilies/wink.gif "[wink] [wink]")
Right, they just hold the checksum.
But is this file only provided to us for verifying the download?
They could also just have this info on the download page. I do check large downloads when this information is available.
Or is it also used by the system itself?
Anyway, why are only some of them available and not all?
I don't know. However, it only takes a second to upload them, so unless someone explains it, I will upload them.
Hi Guys,
Sorry if this has been addressed above, I have skimmed through and couldn't see it.
We have a customer on R11 with a Windows Server installation of One-X Portal. We have upgraded them to the latest R11 version, and run the Log4j patch, but when they do a search of the C drive for Log4j they still see version 2.12.1, which is one of the vulnerable versions. Do you know what this patch is designed to do? Should it have been upgraded to a none affected version (2.17.0 I believe), or have they nullified the vulnerability in some other way?
I need to reassure the customer that the patch has resolved the vulnerability.
Thanks!
Joe
Joe Newton
Sorry if this has been addressed above, I have skimmed through and couldn't see it.
We have a customer on R11 with a Windows Server installation of One-X Portal. We have upgraded them to the latest R11 version, and run the Log4j patch, but when they do a search of the C drive for Log4j they still see version 2.12.1, which is one of the vulnerable versions. Do you know what this patch is designed to do? Should it have been upgraded to a none affected version (2.17.0 I believe), or have they nullified the vulnerability in some other way?
I need to reassure the customer that the patch has resolved the vulnerability.
Thanks!
Joe
Joe Newton
Am I reading this correctly, that to patch the IPO, it has to be on release R11.1 Feature Pack 2? Meaning most my customers would have to be ungraded first?
Also: "Apply the patch to ‘one-X Portal’ service." - The file incudes two versions? Is one or the other used? Both used?
oneXportal-11.1.2001-90.rpm
oneXportal-11.1.2001-90.rpm.SHA256
ACSS
Also: "Apply the patch to ‘one-X Portal’ service." - The file incudes two versions? Is one or the other used? Both used?
oneXportal-11.1.2001-90.rpm
oneXportal-11.1.2001-90.rpm.SHA256
ACSS
- Status