First all Happy 45^2 and thanks for reading my first blog this year!
Last December of 2024, I wrote on blog that addressed security challenges with installing efixes and HIPER fixes.
I like to start this year with good news!
Thanks to your votes on both IBM Ideas, I received feedback from IBM that both issues are being reviewed and may be fixed in this year's fall release. I strongly encourage you to keep voting on those two ideas. This will definitely help us administrators prove that our AIX systems are bulletproof!
https://ideas.ibm.com/ideas/AIX-I-779
https://ideas.ibm.com/ideas/AIX-I-778
I like to share the feedback I got so far from IBM:
IBM is looking at a set of near-term improvements and a longer term more complete solution.
Near term:
IBM is exploring the following to deliver in the service stream:
· Ensure that valid size and hash attributes are set in the entry after applying an efix.
· If item's signature is volatile, the hash will always be verified, even if SIG_VER is on
This is really GREAT! Now we can check that executables, scripts, libs etc. are not tampered, and if we run TE (Trusted Execution) in kernel mode we can block tampered items form execution.
· Update the documentation to make the behaviors more clear.
Longer term:
IBM is exploring to verifying .o signatures at library load time. This will take some invention since the libraries are loaded in the kernel. This will take more time because the final solution will need extensive testing and performance verification. We will target our TL in 2025 for this work.
More great news for signing binaries within efixes:
We can also explore if we can find a way to deliver signatures, at least for binaries, with i-fixes. That will take some redesign of our release engineering and build tools, or possibly some changes to our support delivery processes.
In other words need more time also, but also nice that this is under review.
recap if both ideas are implemented:
I like to explain once more the ideal world after both IBM Ideas are implemented, and why this is so important for us as AIX system admins.
see below a schematic flow for efixes / HIPER fixes:
This flow describes the AIX efixes and HIPER fixes in the ideal patch word, which is not the case yet right now.
I will explain what is implemented and what is not (yet) implemented and why this is important.
Right now implemented:
Most efixes emgr.Z files are provided now with a .sig file, for those we can prove that the efix patch was not tampered during download. Tools that can be used: efix_sec or openSsl to verify the emgr.Z file in combination with the the .sig file.
In the schematic above the right blue box.
Not implemented (yet) now:
The left blue box in the schematic above.
Currently all efixes and HIPER fixes are added to the TE tsd.dat database as type VOLATILE
This is not right, but and this has the following consequences:
The word VOLATILE in the tsd.dat breaks verification, and even the size of an binary is no longer checked, and also not the hash size.
Size and hash size will probably be solved see Near term
In other words a trustchk -n <executable, script, lib > will always pass.
This is dangerous, because this make the applied patches vulnerable.
For example if an script or executable is modified it will not be blocked form execution, neither it will be noticed with a trustcheck -n.
Note:
Even if you do not use trustchk at all, you can use the trustchk -q <path/executable,script,lib,etc.> to see if this item has a valid size hash or signature.
With trustchk -n <path/executable,script,lib,etc.> you can verify is your item is not tampered (only if it not contains the value VOLATILE.
Note: For readers who like to know what HIPER fixes are:
A HIPER (High Impact PERvasive) PTF resolves a problem that might have a high impact on IBM AIX operations or a pervasive problem that affects most systems. HIPER PTFs correct severe problems that occur on your system. HIPER PTFs represent two types of problems: high impact or pervasive and high impact and pervasive.
If you like to read my blog from end last year:
https://community.ibm.com/community/user/power/blogs/christian-sonnemans1/2024/11/29/aix-patch-management-challenges-with-efixes
Another answers I got on this blog:
Automated download challenge for MRS site
Another challenge we have, with efixes / packages that we need to download, is that we cannot automate downloads of the MRS site.
https://www.ibm.com/resources/mrs/assets/packageList?source=aixbp&lang=en_US
we first have to authenticate ourselves with a IBM ID and Password. Sure this is a good thing, but makes it difficult to automate.
Does anyone know if we can download those packages on this side without authentication first, but via a public key / certificate or something?
We like to automate those downloads also, but not this seems not possible.
Answer we got already on the discussion Threads :As per our current plan, we are aiming
“Automated download from MRS” for the TL4 (Fall 2025).
As you may noticed, I like discussions about AIX security and Patch management. Any feedback or commends on this blog is much appreciated. And please to not forget to vote on my two IBM ideas 😊 this will definitely help us to make AIX patch management bullet proof!