I must begin saying that I'm not an AIX expert, just a beginner, but I have this issue/curiosity:
I'm trying to apply openssh fix for AIX :
5.3, 6.1, 7.1, 7.2 IV80743m9a.160127.epkg.Z openssh.base(6.0.0.6201 version) key_w_fix
oslevel -s
7100-00-10-1334
lslpp -L|grep -i openssh.base
openssh.base.client 6.0.0.6103 C F Open Secure Shell Commands
openssh.base.server 6.0.0.6103 C F Open Secure Shell Server
And when I try installing (preview mode):
Verifying prerequisite file ...
Checking prerequisites ...
Prerequisite Number: 1
Fileset: openssh.base.server
Minimal Level: 6.0.0.6201
Maximum Level: 6.0.0.6201
Actual Level: 6.0.0.6103
Type: PREREQ
Requisite Met: no
Prerequisite Number: 2
Fileset: openssh.base.client
Minimal Level: 6.0.0.6201
Maximum Level: 6.0.0.6201
Actual Level: 6.0.0.6103
Type: PREREQ
Requisite Met: no
emgr: 0645-050 Prerequisite number 1 did not pass all checks. Please see
details above.
emgr: 0645-050 Prerequisite number 2 did not pass all checks. Please see
details above.
emgr: 0645-035 Efix package did not pass all preview checks.
Install fails because the minumum prerequisite level is the one that I must install.
Any ideas ?
I was preparing to upgrade AIX to TL1 and try again.
Thank you.
All of the TL would be overkill. You have an interim fix that only applies to the latest cumulative maintenance.
You just need to grab 6.0.0.6201 from FixCentral
You are trying to install something that is not a regular update.
The point is: why are you trying to install an ifix? Is your real intention? If you just want to update openssh, you better get a regular update.
Related
Starting check : CheckJDKVersion
Problem: This JDK version was not certified at the time it was made generally available. It may have been certified following general availability.
Recommendation: Check the Supported System Configurations Guide (http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html) for further details. Press "Next" if you wish to continue.
Expected result: 1.8.0_191
Actual result: 18
Warning: Check:CheckJDKVersion completed with warnings.
Validations are enabled for this session.
Verifying data
Copying Files
Internal Error: File Copy failed. Aborting Install
The log(s) can be found here: C:\Users\KUNAL\AppData\Local\Temp\OraInstall2022-04-10_02-04-52PM.
Press Enter to exit
Your WebLogic server version is not supported with Java 18. You must use Oracle JDK 8.
I found this repo with a systemtap script for letting me use QWERTY ctrl-shortcuts on my dvorak layout. Unfortunately, I can't get it to work, but I don't think it has to do with the script itself. I'm running Pop OS and I think that it's because the linux-image I need with all the debug symbols doesn't exist.
The script says I need to install linux-headers-$(uname -r) linux-image-$(uname -r)-dbg
For me, this turns into linux-headers-5.11.0-7620-generic linux-image-5.11.0-7620-generic-dbg
linux-headers-5.11.0-7620-generic exists and I'm able to download it using apt-get.
linux-image-5.11.0-7620-generic-dbg can't be installed using apt-get. I can install
linux-image-5.11.0-7620-generic, but that's not the same thing. I've spent time looking online for it and adding different keys to apt-get, but I haven't been able to find anything with that name. If the problem is not having the correct linux-image package installed, I need help being pointed in the right direction as to where I can get it.
I tried following the directions here, and I've also searched this to no avail. I tried downloading and installing linux-image-4.4.0-142-generic-dbgsym_4.4.0-142.168_amd64.ddeb but that also didn't work.
If this isn't the problem, I've provided the output of the script. Any help is appreciated.
peyton#pop-os:~/scripts$ sudo stap -g -v dvorak-qwerty.stp
Pass 1: parsed user script and 477 library scripts using 116428virt/91336res/7612shr/83628data kb, in 140usr/30sys/168real ms.
semantic error: resolution failed in DWARF builder
semantic error: resolution failed in DWARF builder
semantic error: while resolving probe point: identifier 'module' at dvorak-qwerty.stp:152:7
source: probe module("evdev").function("evdev_events") {
^
semantic error: no match
semantic error: resolution failed in DWARF builder
Pass 2: analyzed script: 2 probes, 0 functions, 1 embed, 0 globals using 119016virt/94812res/8680shr/86216data kb, in 10usr/0sys/7real ms.
Pass 2: analysis failed. [man error::pass2]
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
Yes, debuginfo downloading has been a pain on many distros. However, if you're running Debian kernels, see: https://wiki.debian.org/Debuginfod for instructions on using a new automated system. Generally: https://sourceware.org/elfutils/Debuginfod.html .
We've got OpenSSL 1.1.1d installed on a windows server 64 Bit running Apache 2.4.*. Everything was working fine until recentlly (Jan 2020) when our daily PCI scan failed with the following synopsis: The remote service is affected by Multiple Vulnerabilities. Obviously the natural thing for me to do was to upgrade to the most recent version of OpenSSL and when I checked https://www.openssl.org/ I found that 1.1.1d is the latest version, I still reinstalled it just to be safe. This did not change anything, the Scan still failed.
The Scan report had a long paragraph at the bottom giving more details about the impact, this text caught my attention...
*"OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time".*
Can anyone out there help me understand what I would need to do to stop this failure? I've had a look around on the internet and no one is reporting the issue in the same context as me. Please help!
UPDATE TO QUESTION - ADDED THE FULL REFERENCED PARAGRAPH
Impact
The version of tested product installed on the remote host is prior to tested version. It is, therefore, affected by the following vulnerabilities : - Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. (CVE-2019-1547) - OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. OpenSSL version 1.1.1 is affected by this issue. (CVE-2019-1549) - OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. (CVE-2019-1552) Note that SecurityMetrics has not tested for these issues but has instead relied only on the application's self-reported version number. See also : http://www.nessus.org/u?c46dca59 https://www.openssl.org/news/secadv/20190910.txt https://www.openssl.org/news/secadv/20190730.txt
It's a false positive. You need to file a dispute with the vendor, showing them that version 1.1.1d does not have the vulnerability found in the other versions. All PCI scan vendors have a process to dispute false positives. If they agree with the results of your dispute, they will remove the vulnerability from your report. They should resolve this issue for you quickly. Send them https://www.openssl.org/news/secadv/20190910.txt, and evidence of the actual version that you have.
I'm now having to answer my own question thanks to the responses by Kapish M and Rodrigo M who gave me crucial information and led me on the right path.
As it turns out, the OpenSSL version installed on a windows server does not supersede version of OpenSSL which is part of the Apache bundle installed as part of XAMPP. The Vulnerability Scanner scans against OpenSSL which is inside Apache (or possibly both but definitely the apache one).
The OpenSSL I had installed on the server version 1.1.1d is completely separate from the one which is part of the XAMPP package (in my case 1.1.1c). The issue I found was that despite having the most up to date version of Apache 2.2.41, the version of OpenSSL shipped with it is not the latest version of OpenSSL and there's no officially documented way of updating just the OpenSSL within the XAMPP package. In fact, the official XAMPP website does say that they do not yet have the 1.1.1d ready for windows, except for Linux (correct at the time of this answer) https://www.apachefriends.org/blog/new_xampp_20191227.html explicitely says OpenSSL 1.1.1d (UNIX only).
Below is what I did to resolve my issue after having had a better understanding thanks to the responses received. I'm still not sure if my approach is safe as this isn't my area of expertise but it definitely got my PCI-Scan to pass.
Installd the latest version of OpenSSL on the Sever
Navigate to the location of the Binaries folder i.e. YourDrive:\Program Files\OpenSSL-Win64\bin
Copy the following files (credit to Edmoncuaft for this list of files)
libcrypto-1_1.dll
libssl-1_1.dll
openssl.exe
Navigate to your apache binaries folder
YourDrive:xampp\apache\bin
[VERY IMPORTANT] Create backup copies of the 3 files mention in step 3 in case you need to revert.
Stop the Apache Server
Copy the 3 files from YourDrive:\Program Files\OpenSSL-Win64\bin to YourDrive:xampp\apache\bin
(Re)Start the Apache Server
These are the steps I followed and when we run the PCI Scan again, it passed with no Vulnerabilities!
I hope this is useful to someone else out there.
I am tying to work/setup the Systemtap tool for profiling OS procesess, on a Virtual Linux. I am using VirtualBox to run the image. Via
rpm -q kernel
and
cat /proc/version
The version obtained is:
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze4)
I have correctly downloaded and installed the tool and wrote a simple program (.stp). However I keep getting the same error, which I have searched information in many places without success:
After executing:
sudo stap my_profiler.stp
I get:
semantic error: libdwfl failure (all kernel modules found): no error
Pass 3: translation failed. Try again with another '--vp 001' option.
According to https://sourceware.org/systemtap/SystemTap_Beginners_Guide/errors.html
semantic error: libdwfl failure
There was a problem processing the debugging information. In most cases, this error results from the installation of a kernel-debuginfo package whose version does not match the probed kernel exactly. The installed kernel-debuginfo package itself may have some consistency or correctness problems.
I have found no relevant information on the "kernel-debuginfo" package. I have also tried the verbose option without benefit. I even tried with an old Snapshot of the VM. Any ideas?
The code of the .stp program I ran:
probe timer.profile{
printf("Process: %s\n", execname())
printf("Process ID: %d\n", pid())
}
Found the problem!!!! It seemed that I was using the wrong version of the Linux Kernel. I was using the default kernel supplied by the version I wrote in the question. It seems that that version (the 2.6.32-5-686 one) has problems with the debug-info so all I did was try the same with another version (the Linux version 3.9.6 with gcc version 4.7.2 Debian 4.7.2-5) and it worked without trouble :)
I use emerge to check the status of ebuild, and I get this:
gentoo ~ # emerge -pv libvirt
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-emulation/libvirt-0.9.10-r4 USE="libvirtd lxc nls policykit python udev -avahi* -caps -debug -iscsi -lvm -macvtap -nfs -numa -openvz -parted -pcap -phyp -qemu -sasl* (-selinux) -uml -virt-network* -virtualbox* -xen" 0 kB
The USE label avahi*, virt-network*, sasl*, virt-network* virtualbox* , what does the '*' mean in these labels. Thanks. I think these packages are already installed . Right?
Just look at man page: http://linuxreviews.org/man/emerge/ Everything is explain there.
'R' stands for: rebuild (specific version of package is installed already)
'*' stands for: change from/to enabled state' - If use flags changed, portage will prompt you to rebuild packages because the use flags might have a significant impact on package functionality.
Compared to your currently installed libvirt, this new emerge will remove avahi module.
This might come from several possibilities :
Change in make.conf USE
Change in /etc/portage/package.use
Change of profile
Previously compiled libvirt with forced USE flags (i.e. USE="avahi" emerge libvirt)