This information is not sensitive.
An attacker would gain very little by knowing these facts beforehand. Many of them are either not relevant to their campaign, or trivial to detect remotely, even if the configuration is not published. In order to answer adequately, you may want to elaborate on what you mean by "break in". Is the attacker attempting to bypass authorization remotely? Do they have a local process running on the system and are attempting to elevate privileges? Are they trying to root a commercial embedded system that they have purchased and have physical access to? Hiding this information may slow down someone who is trying to jailbreak a commercial system for a short amount of time by forcing them to spend time reverse engineering it, but it will do nothing against an attacker with a local shell trying to get root.
There is only one situation where hiding certain information is beneficial, and that is when an attacker is attempting mass-exploitation of a remote vulnerability. Having your application withhold its exact version can decrease the chance that an army of bots scanning the entire internet will attempt to exploit you. This will not protect against anyone who is looking to exploit you specifically, however.
Details you are trying to hide
The processor family itself tends not to matter. The overwhelming majority of exploits, of all kinds, will work equally well on Skylake as on Kabylake. If you're talking about processor architectures, then it starts to matter, as MIPS shellcode will not work on an ARM system, and vice versa. However, this is not something that should be obscured, as the majority of servers and systems in general are running x86, mobile systems tend to run ARM, and embedded systems often run MIPS.
Whether or not the operating system even needs to be known depends on what is being exploited. If a web app is being attacked, the operating system may not even be relevant. A SQLi vulnerability in a popular web platform will work equally well on Windows, Linux, FreeBSD, Solaris, or any other operating system that can run the vulnerable application. If the attacker is trying to attack the system itself to elevate privileges, it may be necessary to know the operating system. This information can be obtained remotely through a technique known as OS detection, or OS fingerprinting.
There are some libraries that will generally always be used. You will practically never find something that does not link against
libc. A program doing math will likely use
libm. A program that accepts user input via CLI will likely use
libreadline. There are not many exceptions. If an attacker is trying to exploit a program, they only need to know the libraries in use if they are exploiting a particular vulnerability in the library. It's easy to check which libraries a program needs, as the list is encoded into the executable itself. Various scripts like
ldd can gather this information from an executable.
Application programming language
The programming language for a vulnerable program may matter, depending on the type of exploit that is being used. A language like PHP which does its own memory management (is memory-safe) tells you that you will not need to attempt a stack overflow, as memory is managed. A C program on the other hand may be vulnerable to such a bug, as it is lower level. Knowing the language itself is neither necessary, nor sufficient for exploitation. The overlap in knowledge between a person who knows enough about a program to exploit it, and a person who does not know the language it uses, is zero.
Standardised protocols used
Some protocols are more vulnerable than others. DCCP for example has a history of nasty vulnerabilities. Rather than attempting to hide the protocols you are using, it would be far better to disable the unnecessary ones, as an attacker can simply attempt a connection with said protocol to see if it is supported. If the connection fails, it is either unsupported, or the port is closed. Either way, attacking the protocol itself will not be possible if it is not open and supported.
Types of attackers
There are different types of attackers. For this answer, let's split up the types of attackers into local, remote, and physical, and see what position they are in to gather the information they need.
A local attacker is running a process on your system. They want to elevate their privileges, or move laterally to other users. They may or may not be sandboxed. A local attacker is one of the most dangerous, as they have access to any information the operating system willingly gives out.
- Processor family - Unnecessary, but can be retrieved in
- Operating system - If they are running locally, they most likely already know the operating system.
- Libraries - If they have access to the executable, then can run
readelf on it.
- Language - Checking the libraries in use gives away the runtime, revealing the language.
- Protocols - Using the
socket() syscall can allow testing if a given protocol is supported.
A remote attacker is trying to compromise a server. Their only interaction with the target is over the network, subject to any firewall rules that may be in play. They want to gain unauthorized access to the system by exploiting vulnerabilities in remotely running services.
- Processor family - Unnecessary to know, but can probably be guessed.
- Operating system - Many tools can remotely reveal the operating system being used.
- Libraries - Very few remote exploits need to know the specific libraries being used.
- Language - If they know a service well enough to attack it, they know the language.
- Protocols - An attacker can attempt to connect using a particular protocol. If it fails, it is either not supported or firewalled off. The attacker does not care about the distinction.
A physical attacker has your device in their hands. They may be trying to reverse engineer it and jailbreak it to expand its functionality or access secrets it is storing. They can open the device, look at the labels on the components, dump firmware, and possibly even attach the CPU to a debugger. This is the most powerful class of attacks. There is generally no way to prevent a physical attacker from gaining detailed information about your system, given enough time.
- Processor family - This can be determined by reading the CPU's datasheet.
- Operating system, libraries, language, and protocols - Dumping the firmware reveals this.
In general, this information is either easy to find out, not necessary to know, or difficult to hide. There are far better ways to improve your security. Now, what you should do, rather than hiding the following:
- Processor family - Make sure you are using a modern processor with valuable security features like NX, SMEP, and RDRAND. A good operating system can take advantage of processor security features to enhance your security. CISC systems are easier to exploit using ROP. Systems with out-of-order and speculative execution can be vulnerable to side-channel attacks.
- Operating system - Use a secure operating system, kept up to date and configured securely. OpenBSD is more secure than an old Windows server. Linux with grsecurity is more secure than a poorly maintained CentOS system. A custom kernel configuration or whitelisted modules can allow you to disable unnecessary drivers and other risky features.
- Libraries used - Ensure all your libraries are kept up to date. If a vulnerability is discovered in a library, update it and restart any application that is running and which links against it.
- Application programming language - When possible, use a language that is memory-safe. It is harder to get things wrong when writing in python than it is when writing in C.
- Standardised protocols used - Only enable the protocols you need. Unnecessary protocols may be exploitable locally or remotely. If you have whitelisted your protocols to only the core basics necessary to run adequately, exploiting you through a networking vulnerability will be much harder.
While there is no reason to reveal all this information (assuming you are not expecting collaboration, where revealing information can help people point out bugs for you to fix), some of the details you mention are either so irrelevant or so easy to detect that you would have to go to excessive lengths to hide that information. Simply disabling version information is one thing. Wasting effort trying to prevent someone from knowing if you are on an x86 system or a SPARC system is just unnecessary.
Some resources you might be interested in: