Lucene search

K
attackerkbAttackerKBAKB:FB2F65B2-D10B-4622-AEE6-41AAD3C1E6E7
HistoryDec 20, 2019 - 12:00 a.m.

CVE-2019-17571

2019-12-2000:00:00
attackerkb.com
35

9.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

7.5 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:P/I:P/A:P

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

Recent assessments:

space-r7 at October 05, 2020 10:35pm UTC reported:

This vulnerability is essentially a duplicate of CVE-2017-5645, which was discovered in various versions of Log4j 2. I am unsure why the Log4j 1.x versions were addressed later, especially since Log4j 1.x was considered EoL in 2015.

Including any of the vulnerable versions of the Log4j library and enabling it in the application of choice opens up a pretty nasty vulnerability in said application. The CVE listing mentions that the vulnerability exists within the SocketServer class. Within its main() method, a SocketNode object is created once a client connection is accepted.

public static void main(String argv[])
{
   ...
      while(true) {
	cat.info("Waiting to accept a new client.");
	Socket socket = serverSocket.accept();
	InetAddress inetAddress =  socket.getInetAddress();
	cat.info("Connected to client at " + inetAddress);

	LoggerRepository h = (LoggerRepository) server.hierarchyMap.get(inetAddress);
	if(h == null) {
	  h = server.configureHierarchy(inetAddress);
	}

	cat.info("Starting new socket node.");
	new Thread(new SocketNode(socket, h)).start();
   ...
}

The SocketNode constructor creates a new ObjectInputStream object named ois from data on the socket:

  public SocketNode(Socket socket, LoggerRepository hierarchy)
  {
    this.socket = socket;
    this.hierarchy = hierarchy;
    try {
      ois = new ObjectInputStream(new BufferedInputStream(socket.getInputStream()));
    ...
  }

And in the SocketNode’s run() method, readObject() is called on the data previously read from the socket:

public void run()
 {
    LoggingEvent event;
    Logger remoteLogger;

    try {
      if (ois != null) {
          while(true) {
	        // read an event from the wire
	        event = (LoggingEvent) ois.readObject();
	        // get a logger from the hierarchy. The name of the logger is taken to be the name contained in the event.
	        remoteLogger = hierarchy.getLogger(event.getLoggerName());
  ...
 }

This vulnerability could give an attacker unauthenticated RCE easily if and only if the Log4j library is enabled and listening for remote connections. I’m rating this vulnerability a little lower in utility / attacker value because of that. This is quite an old vulnerability despite the CVE date, but as always, make sure you’re patched.

Assessed Attacker Value: 3
Assessed Attacker Value: 3Assessed Attacker Value: 3

References

9.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

7.5 High

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:P/I:P/A:P