문제
Java 기반 애플리케이션용으로 많이 사용되는 로깅 라이브러리인 Apache Log4j2에 심각한 보안 취약성이 보고되었습니다. 다음 취약성이 분석되었습니다.
| 취약성 | 영향을 받는 것 | 영향을 받지 않는 것은 무엇입니까? | 상태 |
| CVE-2021-44228 |
|
|
이러한 문제가 해결되었습니다. 수정 사항과 완화 단계에 대한 해결 방법 섹션을 참조하십시오. |
| CVE-2021-45046 | |||
| CVE-2021-45105 | 즉시 사용 가능한 로깅 구성 덕분에 Experience Manager Forms 릴리스에 영향을 주지 않습니다. 추가 로깅 구성이 있는 경우 이러한 구성에 이러한 취약성이 있는지 확인하십시오. |
||
| CVE-2021-44832 | |||
| CVE-2021-4104 | |||
| CVE-2022-22963 | |||
| CVE-2022-22965 | |||
| CVE-2020-9488 | |||
| CVE-2022-23302 | |||
AEM 6.5.13.0 Forms 및 이전 릴리스에는 Log4j 라이브러리(1.x 및 2.17.1)이 모두 포함되어 있습니다. AEM 6.5.13.0 Forms 및 이전 릴리스의 AEM Forms Log4j 1.x 라이브러리는 Adobe에 의해 수행되는 AEM Forms 코드 스캔에서 보고된 취약하거나 기록되지 않는 취약성의 일부가 아닙니다. 그러나 모든 Log4j 1.x 라이브러리는 6.5.14 릴리스에서 제거되었습니다. AEM 6.5.14.0 이상의 릴리스를 설치하는 방법은 릴리스 노트를 참조하십시오.
해결 방법
다음 방법 중 하나를 사용하여 이 취약성의 위험을 줄일 수 있습니다.
- 최신 서비스 팩 설치
- 수동 완화 단계 사용
최신 서비스 팩 설치
Experience Manager Forms 서비스 팩 6.3.3.8 또는 Experience Manager Forms 서비스 팩 6.4.8.4 환경에 핫픽스를 적용한 경우 취약성 수정 사항(아래 나열)이 포함된 서비스 팩을 설치하지 마십시오. 이러한 서비스 팩을 설치하면 핫픽스를 덮어쓸 수 있습니다. Adobe는 이러한 시나리오에서 수동 완화 단계를 권장합니다.
| 해제 | 버전 | 다운로드 링크/사용자 작업 |
| JEE의 Experience Manager 6.5 Forms | AEMForms-6.5.0-0038(log4jv2.16) |
소프트웨어 배포에서 다운로드하십시오.
|
| JEE의 Experience Manager 6.4 Forms | AEMForms-6.4.0-0027 | |
| JEE의 Experience Manager 6.3 Forms |
AEMForms-6.3.0-0047 | |
| Experience Manager 6.5 Forms Designer | AEM Forms Designer v650.019 | |
| Experience Manager 6.4 Forms Designer | AEM Forms Designer v640.012 | |
| automated forms conversion Service | 완화 단계가 확인되었고 서비스가 패치되었습니다. | 사용자 작업이 없습니다. |
수동 완화 단계 사용
문제를 완화하려면 Experience Manager 6.5 Forms(log4j-core 버전 2.10 이상), Experience Manager 6.4 Forms(log4j-core 버전 2.10 이전) 및 Experience Manager 6.3 Forms(log4j-core 버전 2.10 이전)의 경우 다음을 수행합니다.
1. 모든 서버 인스턴스 및 로케이터를 종료합니다.
2.다음 위치에 있는 취약한 log4j-core-2.xx.jar에서 org/apache/logging/log4j/core/lookup/JndiLookup.class를 제거합니다.
- 배포 가능한 EAR: <FORMS_INSTALLATION_DIRECTORY>/configurationManager/export/adobe-livecycle-[jboss|weblogic|websphere].ear
- GemFire 또는 Geode 로케이터:
<FORMS_INSTALLATION_DIRECTORY>/lib/caching/lib
- (Oracle WebLogic 또는 Redhat JBoss가 있는 Linux): 다음 명령을 실행합니다. 다음 명령을 실행하기 전에 <version> 및 애플리케이션 서버 정보를 업데이트합니다.
- unzip adobe-livecycle-<weblogic|jboss>.ear lib/log4j-core-<version>.jar
- zip -d lib/log4j-core-xxx.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- zip -ru adobe-livecycle-jboss.ear lib/log4j-core-<version>.jar
- (IBM WebSphere가 있는 Linux): 다음 명령을 실행합니다. 다음 명령을 실행하기 전에 <version> 및 애플리케이션 서버 정보를 업데이트합니다.
- unzip adobe-livecycle-websphere.ear log4j-core-<version>.jar
- zip -d log4j-core-xxx.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- (Microsoft Windows): 7-Zip과 같은 GUI 도구를 사용하여 클래스 파일을 제거합니다.
3. 각 애플리케이션 서버 인스턴스(노드) 및 모든 로케이터(둘 이상의 경우)에 대해 2단계를 반복합니다.
4.jar를 업데이트한 후 수정된 EAR을 다시 배포하고 모든 로케이터 프로세스와 서버 인스턴스를 다시 시작합니다.
- log4j-core-2.xx jar의 원본을 업데이트된 사본으로 바꿉니다.다른 변경 사항은 필요하지 않습니다.
- 구성 관리자가 다시 실행되면 <FORMS_INSTALLATION_DIRECTORY
>/configurationManager/export의 내용을 덮어쓸 수 있습니다. 이러한 일이 발생할 때마다 위의 변경 사항을 다시 실행하지 않으려면 <FORMS_INSTALLATION_DIRECTORY>/deploy/adobe-core-[jboss|weblogic|websphere].ear에서 jar를 업데이트합니다. 이렇게 하면 구성 관리자가 생성한 adobe-livecycle-[jboss|weblogic|websphere].ear에 이미 업데이트된 log4j-core-2.xx jar가 있습니다.
- 배포 가능한 아티팩트에 대한 수동 수정은 패치/업그레이드 시 덮어쓸 수 있습니다. 이 경우 절차를 다시 적용합니다.
참조