BOINC 7.9.2 releases security information

[MarkJ62]

With BOINC now providing the Glibc version information it is now available for users and hackers to exploit. Below is a Raspberry Pi that was updated and now shows this information on the project server (Einstein in this case).

Linux Raspbian Raspbian GNU/Linux 9.3 (stretch) [4.9.59-v7+|libc 2.24 (Debian GLIBC 2.24-11+deb9u1).

That shows the version, but also says its had deb9u1 applied which is a security fix. The lack of that information could be used in a targeted attack that the security fix was patching.

We should only return the version number portion for security reasons (ie the 2.24).

[ChristianBeer]

How could this information be exploited by a hacker? The vital information about IP-Adress and hostname are hidden from the public. All the attacker sees is meta information about a host of someone he doesn't even know the email of. The attacker needs to correlate data from other sources to connect a certain host on a BOINC project with an actual person and then find a way to contact that person with the malicious payload. While doing this kind of research one usually finds easier ways to attack the user.

When coding this I thought about truncating the extra information but then again this could be helpful to the project to know so I let it in. The kernel version is a more likely candidate to expose security information so we need to truncate this information too which will in turn limit the troubleshooting done by projects and volunteers.

This should not sound like I dismiss the issue but I don't think it's that big of a deal.

[Ferroin]

@ChristianBeer You're assuming this is only of use for an attack that involves social engineering as the means of injecting malicious code. By sheer volume, most attacks do that, but most aren't successful, so why should anyone waste their time on them (aside from bulk attacks being easier that way)? If the attacker has your IP address, they don't need to know who you are to attack your system. Such an attack is of course much more difficult, but knowing what software versions the target system is running does help significantly.

[ChristianBeer]

That was my point. If someone knows an IP address how does he know which host on a certain BOINC project does it belong to?

[Ferroin]

Ah, I misunderstood what you meant, sorry.

[TheAspens]

@MarkJ62 - what attack vectors do you see being enabled with this additional information given that you do not have access to the IP address of the relevant host?

[MarkJ62]

Given CPDN has been hacked a number of times in the past one cannot assume the IP addresses aren’t known. Yahoo has been hacked numerous times too. Facebook is currently in the news for giving information to Cambridge Analytica.

You can’t make the assumption that a users IP address isn’t known, therefore it’s okay to disclose the patch level of Glibc and/or the kernel.

This is a compromise between giving the project developers enough information to do their job and not give out too much that a hacker could use it. Earlier BOINC versions never had the Glibc version so you are still getting more than before with just the major and minor version numbers.

[JuhaSointusalo]

Lets say a bad guy manages to break into project servers. He won't be able to do any easy bad things like adding a malicious project to users BOINC installations or, assuming signing keys are not compromised, add or change science apps to malware. What the bad guy could do is change users' preferences or send them tasks he created.

glibc had two years ago a critical bug in getaddrinfo. I'm not entirely sure but I think it's exploited by giving an app a URL that points to a domain an attacker controls. As it happens, BOINC client deals a lot with URLs. So, the bad guy could create tasks with input files residing on a domain he controls. Any system that has vulnerable glibc has BOINC client pwned.

Or the same with user preferences. Seti@home screensaver allows users to choose logo and background images and the screensaver loads them from Internet. (I don't really know if it still works, the settings are still in preferences but I haven't used them.) The bad guy changes user preferences to loads images from the bad domain and the screensaver is pwned.

Now, the bad guy could target all the hosts on the project including ones where glibc has already been patched. He won't be able to cover his tracks on patched hosts which increases the chances that someone sees something odd and alerts the project. If he knows which hosts are vulnerable he could target only those hosts and maybe stay hidden a while longer. Matching user preferences and host details is easy and BOINC has built-in functionality to send a task to any particular host.

I might have gotten the details about getaddrinfo wrong but it doesn't matter, the principle still holds. There is always a new vulnerability and instead of attacking the client the bad guy could attack science apps. How many project scientist are fuzzing their science apps?

So I have to side with @MarkJ62 here. While including the patch level of libc is not massively bad it's not good either.

[RichardHaselgrove]

Trying to brainstorm another problem, I've just noticed this event log message in the header reply from an active BOINC server (which had better remain nameless for the time being).

Received header from server: Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_auth_gssapi/1.3.1 mod_auth_kerb/5.4 mod_fcgid/2.3.9 PHP/5.4.16 mod_wsgi/3.4 Python/2.7.5

Does that level of server verbosity raise similar concerns?

[JuhaSointusalo]

@RichardHaselgrove

From Apache FAQ: How can I change the information that Apache returns about itself in the headers?

When a client connects to Apache, part of the information returned in the headers is the name "Apache" Additional information that can be sent is the version number, such as "2.2.17", the operating system, and a list of non-standard modules you have installed.

For example: Server: Apache/2.2.17 (Unix) mod_perl/1.26

Frequently, people want to remove this information, under the mistaken understanding that this will make the system more secure. This is probably not the case, as the same exploits will likely be attempted regardless of the header information you provide. ...

And Apache config: ServerTokens

Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety.

So how does that compare to our libc information? Web servers are probably constantly under attack and attempting an attack only when it's known to succeed might not gain much for the attacker. Volunteer machines on the other hand are probably not as much under attack. It might be beneficial for the attacker if they can launch only successful attacks in order to show up in as few logs as possible.

But I'm not a security expert and I don't know how attackers think. It could be just as well that they launch an attack against all the hosts as soon as they can and are happy with that.

[brevilo]

While including the patch level of libc is not massively bad it's not good either.

I think the point here is: the patch level is just part of how Debian does its versioning and we're just retrieving version information. That said, the version information is very useful during debugging, like any other similar host details. If that version detail might contain sensitive information then we need to consider removing it from the public host pages, like the IP or domain name. The project admins and the user would still be able to see it.

Isn't it that simple or what am I missing?