DirectAdmin 1.52.0 has been released - Security fix!

Yes ./build nginx did the trick. I now have http/2!!;)

Fantastic! This server supports HTTP/2.
ALPN: ALPN Supported
This server supports Application-Level Protocol Negotiation. ALPN is a TLS extension that helps client and server negotiate the HTTP protocol (h2 in this case) during the TLS handshake. This avoids the need to make a regular HTTP/1.1 request in order to establish an h2 connection.

Thanks for your help.
 
This is not the thread for MariaDB, but I want to let you know that in MariaDB 10.2.x strict mode is enabled as default, and my guess is that is causing some of your trouble. Try to disable strict mode. https://mariadb.com/kb/en/library/sql-mode/#strict-mode

fwiw once I found correct way to apply it globally (as this server only handles this one script and 2 test sites based on same script) in my.cnf this was the issue.
so now letting it run week or so and starting to retune DB
 
@dmacleo, Could you please share how you correctly applied strict mode globally? I have not upgraded to 10.2.x yet, so it would be helpfull. Also maybe helpfull for others. :)
 
@dmacleo, Could you please share how you correctly applied strict mode globally? I have not upgraded to 10.2.x yet, so it would be helpfull. Also maybe helpfull for others. :)


sql-mode = ""

in my.cnf seems to have applied it correctly to all sites/databases
again, this is pretty non-standard setup. the server only handles a clipbucket ffmpeg site that feeds another site (using embed) and 2 test sites to test stuff with
 
I'd like to bring this under everyone's attention again:

The important security bug is already exploited and abused in the wild. They can access your servers as root with this DirectAdmin bug (segfault).

So, if you have DirectAdmin exposed to the world you MUST update as soon as possible or apply this workaround:

https://www.directadmin.com/features.php?id=2036

EDIT:

You can check the logs to see if attackers tried/gained access:
Code:
cat /var/log/directadmin/*.log | grep CMD_CHANGE_FTP_PASSWORD

If you see a result like the one below, then your server MAY have been comprimised:
Code:
19/01/2018:13:37:00 <ip_from_attacker> POST /CMD_CHANGE_FTP_PASSWORD HTTP/1.1 (null)
 
Last edited:
I noticed there's no security update notice in custombuild for this - which surprised me.
 
Yes, custombuild 2.0 will let you know with:
Code:
./build versions
should spit out:
Code:
Security update is available.: Update DirectAdmin to 1.52.0 or higher: https://www.directadmin.com/features.php?id=2036
or similar messages with various wordings, depending on if the OS is end-of-life, how the settings currently are, etc..

If the email_ftp_password_change=0 is set, it won't throw the notice.

The CustomBuild 2.0 plugin will also include the notice in it's versions output, as a security section.

Either way, at this point, I'm tempted to just have CB2 automatically shut off the password feature the moment build runs if DA is old, regardless of warnings, etc..

John
 
I should of left the machine as it was until we had a chance to look, because I was definitely on 1.51.x and custombuild 2 didn't complain about the version.

I don't have a value set for email_ftp_password_change, so I'm presuming the internal value is 1?
 
Correct, check with
Code:
/usr/local/directadmin
./directadmin c | grep email_ftp_password_change
 
Yes, custombuild 2.0 will let you know with:
Code:
./build versions
should spit out:
Code:
Security update is available.: Update DirectAdmin to 1.52.0 or higher: https://www.directadmin.com/features.php?id=2036
or similar messages with various wordings, depending on if the OS is end-of-life, how the settings currently are, etc..

If the email_ftp_password_change=0 is set, it won't throw the notice.

The CustomBuild 2.0 plugin will also include the notice in it's versions output, as a security section.

Either way, at this point, I'm tempted to just have CB2 automatically shut off the password feature the moment build runs if DA is old, regardless of warnings, etc..

John

John,

What stops you from notifying your customers through the client portal and forum ? Everyone below this version with not that particalar config line will be subject of a easy walk in, into your box. And with escalation to a root user. Also i bet you can see who is updated and who not. Feels more like passive downplaying instead of standing up and taking active responsibility

2 cents.
 
Did just that but no http/2. What am I missing?
DA version 1.52.0
CentOS Linux release 7.4.1708 (Core)
OpenSSL 1.0.2k-fips 26 Jan 2017
Custom Build 2.0.0 (rev: 1733)

options.conf
#PHP Settings
php1_release=5.6
php1_mode=php-fpm
php2_release=7.0
php2_mode=php-fpm

#WEB Server Settings
webserver=nginx_apache

Edit: It seems ALPN is not supported.

Didn't CentOS/RHEL 7.4 add in support for ALPN?

openssl rebased to version 1.0.2k
The openssl package has been updated to upstream version 1.0.2k, which provides a number of enhancements, new features, and bug fixes, including:
Added support for the Datagram Transport Layer Security TLS (DTLS) protocol version 1.2.
Added support for the automatic elliptic curve selection for the ECDHE key exchange in TLS.
Added support for the Application-Layer Protocol Negotiation (ALPN).
Added Cryptographic Message Syntax (CMS) support for the following schemes: RSA-PSS, RSA-OAEP, ECDH, and X9.42 DH.
https://access.redhat.com/documenta.../html/7.4_release_notes/new_features_security

I also see the notes on How-to: Enable HTTP/2 in Apache/Nginx/cURL have been updated to say if the OS has support for ALPN by default it will build Apache with HTTP2 support and CentOS 7.4 is on the list.
 
John,

What stops you from notifying your customers through the client portal and forum ? Everyone below this version with not that particalar config line will be subject of a easy walk in, into your box. And with escalation to a root user. Also i bet you can see who is updated and who not. Feels more like passive downplaying instead of standing up and taking active responsibility

2 cents.

I second this. We keep things up-to-date but still DirectAdmin should be pro-active with this kind things.
 
+1, yesterday was hacked through this vulnerability.
Why did not you do the mailing on the license database? =(
 
+1, yesterday was hacked through this vulnerability.
Why did not you do the mailing on the license database? =(
1.53 has been out since 14th March..... 1.52 since 3rd October 2017

No excuses not to upgrade, CB informs you, so does DA
 
Last edited:
Back
Top