1

Recently, a tweet from cURL author Daniel Stenberg caused a lot of buzz. In the article, he politely "returned" to the unreasonable request from a Fortune 500 company for its technical support "white prostitution" - "either pay or shut up!"

It is reported that the cause of the incident was a US Fortune 500 company due to the Apache Log4j vulnerability incident in December last year, and an email (the company or its customers may be using cURL) asked a series of questions to Find out if cURL depends on Log4j, and ask the author of cURL to reply as soon as possible and free of charge within 24 hours of receiving this email.

Below the original text of the email, the Fortune 500 company (represented by NNNN) also lists a series of questions to be answered by cURL author Daniel Stenberg:

Has your company experienced any proven security incidents?
If so, which applications, products, services and related versions are affected?
Are any of NNNN's products and services affected?
Was NNNN non-public or personal information affected?
If so, please provide NNNN with details of the affected information immediately.
What is the timeline for completing the remedial action? List the steps and include the date of each step.
What action is required by NNNN to complete this remedy?
……

After receiving this email, Daniel Stenberg, the author of cURL, was amused because he had never been involved in any Log4j development, which means he had nothing to do with it.

But since the email asked him to reply as soon as possible, he also responded politely and "restrainedly": "As long as we have signed a support contract, I will reply immediately." At the same time, he also tweeted about the incident:

"If you're a multi-billion dollar company, when you care about Log4j, why not email those OSS authors you never paid anything to ask them to reply to a ton of messages for free within 24 hours and show receipt mail?"

cURL author "responds": the level of ignorance in the email is shocking

It may be that this thing is really a bit too baffling, and Daniel Stenberg then wrote a blog post to evaluate this thing:

"I received this email on Friday 21st January 2022. I tweeted this and left.

This email is from a multi-billion dollar Fortune 500 company that apparently may use a product containing my code, or they may have such a client. Who knows?

I'm guessing they do this for compliance reasons, they "forget" that their open source components are not automatically provided by "partners" who can simply ask for that information.

I responded very briefly to this email and said I would be happy to respond with details once we have signed a support contract.

I think this might be a good example of the open source pyramid pattern, where people at the top don't think about how to maintain the bottom at all. You can build a house without worrying about the ground the house is on. "

......

"The level of ignorance and incompetence displayed in this email is appalling.

While they don't even specify what product they're using, any code or copyrighted code I'm involved in doesn't use log4j, which any novice or better engineer can easily find.

In the image version of the email, I filled in the name field to better anonymize the sender, and in the text below I replaced it with NNNN. (Yes, it's very strange that they are sending requests to log4j now, apparently late.)"

In Daniel Stenberg's tweets and blog posts, he removed the Fortune 500 company's name and gave the reason: I may have the right to tell you who they are, but I still don't want to. (Especially if I can sign a favorable commercial contract with them).

cURL author stresses: "has nothing to do" with Log4j events

Back on December 9th last year, a vulnerability was discovered in the Apache Log4j logging library. This library is typically used for Java/J2EE application development projects, as well as publishers of Java/J2EE-based off-the-shelf software solutions.

Log4j includes a search mechanism that can be used to query via special syntax in format strings. For example, it can be used to request various parameters such as Java environment version via $Java:version etc. Then, by specifying the jndi key in the string, the search mechanism uses the jndi API. By default all requests use the prefix java:comp/env/*; however, the author has implemented the option to use a custom prefix with a colon in the key. This is where the vulnerability lies: if jndi:ldap://is is used as the key, the request will be sent to the specified LDAP server (other communication protocols such as LDAP, DNS and RMI can also be used).

As a result, a remote server controlled by an attacker could send objects back to a vulnerable server, potentially leading to arbitrary code execution in the system or disclosure of confidential data. The attacker simply sends a special string through the mechanism that writes the string to the log file, which is then processed by the Log4j library. This can be done with simple HTTP requests, such as sending requests via web forms, data fields, etc., or any other type of interaction using server-side logging.

This vulnerability is considered to be the most important and severe in the past decade.

In this regard, the author of cURL questioned:

cURL (client-URL-request-library:URL-request-library for clients or see-URL:see-URL) is a command-line interface for retrieving the content of a computer network-accessible resource. Resources are specified using URLs and must be of a software-supported type. The software allows users to create or modify resources (unlike wget), so it can be used as a REST client.

The cURL program implements the user interface and is based on the libcurl software library developed in C language. Therefore, the library is accessible to developers who wish to have network access in their programs. Interfaces have been created in multiple languages​​​(C++, Java, .NET, Perl, PHP, Ruby…).

La bibliothque supports File, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAP, POP3, POP3, RTSP, SCP, SFTP, SMB, SMB, SMTP, SMTPS, Telnet and other TFTP protocols.

As you can see, the cURL open source code has nothing to do with Log4j events. Still, in this case, cURL author Daniel Stenberg was contacted by a Fortune 500 company in the context of the Log4j vulnerability.


MissD
955 声望40 粉丝

引用和评论

0 条评论