I know SSHv1 is super insecure, however I need to set it up on a server for some testing. Trying to find an older version of openSSH was a hard task in itself, but now trying to set it up is impossible.
I'm trying to use openSSH 2.1.1 and openSSL 1.0.1.
From what I can tell, openSSL installs fine, however I run in to issues with openSSH
My configure (./configure --prefix=/usr --sysconfdir=/etc) works fine, however I run in to issues when I try to make
The error I'm getting is: authfd.c:354:41: error: dereferencing pointer to incomplete type ‘RSA {aka struct rsa_st}’ buffer_put_int(&buffer, BN_num_bits(key->n));
I've tried looking around, and have even started looking in some of the openSSL files, I think everything is coded correctly.
My guess is that these errors have something to do with trying to compile old versions of ssl and ssh with an up to date version of gcc
Has anyone managed to set up a server to use SSHv1, or at least have any ideas on how to solve this dereferencing error?
From the error you see it looks like you are using OpenSSL 1.1.0, which made RSA structures opaque and is therefore it is not compatible. Things to resolve:
Download older OpenSSL (1.0.2 should do that) and build this one
Configure with --with-ssh1 switch to enable SSH1 support
Related
I'm attempting to try out some modifications in SAP's Privileges.app. Unfortunately, their (understandable) Support policy is
This project is 'as-is' with no support, no changes being made. You are welcome to make changes to improve it but we are not available for questions or support of any kind.
Unfortunately, this app uses two constructs I've never come across before in my professional experience, an XPC service + helper (Launch daemon?) and a DockTile plugin. I'm having a hard time just fundamentally getting the app to work when launched from Xcode - it launches, but it seems that there are issues between (maybe?) sandboxing, signing and perhaps entitlements? I've updated the signing to use my own team, of course, and everything compiles/links/launches properly, but when the XPC service tries to install the helper tool it fails
2022-06-29 17:03:56.284544-0500 PrivilegesXPC[13079:128535] [logging-persist] cannot open file at line 45530 of [9ff244ce07]
2022-06-29 17:03:56.284570-0500 PrivilegesXPC[13079:128535] [logging-persist] os_unix.c:45530: (0) open(/var/db/DetachedSignatures) - Undefined error: 0
2022-06-29 17:04:21.060214-0500 PrivilegesXPC[13079:128537] SAPCorp: ERROR! Failed to connect to helper tool: NSCocoaErrorDomain / 4097
2022-06-29 17:04:31.471555-0500 Privileges[13064:127420] SAPCorp: ERROR! Error Domain=NSPOSIXErrorDomain Code=25 "Inappropriate ioctl for device"
2022-06-29 17:04:45.717751-0500 Privileges[13064:129162] SAPCorp: ERROR! Installation of the helper tool failed: Error Domain=CFErrorDomainLaunchd Code=4 "(null)"
As near as I can tell, the last two errors are thrown from a failure in
success = SMJobBless(
kSMDomainSystemLaunchd,
CFSTR("corp.sap.privileges.helper"),
self->_authRef,
&error
);
but I haven't been able to ascertain why this is failing. Searching for errors around Inappropriate ioctl for device has not been fruitful, unfortunately.
If there's anyone out there with some experience in dealing with apps using some of these more esoteric moving parts that can share some things to try, I'd be much obliged. Bonus points if there's any way to debug code running in a DockTile plugin - as near as I can tell, it's running in SystemUIServer, but I can't attach to that (even as root) from Xcode.
I think I've sorted out getting this running. Here's a few roadblocks I encountered.
SMJobBless has some very particular expectations around code-signing - you'll find references to this in some forum posts and there's a sample project that's also referenced with a utility script - which doesn't run on modern macOS because it's written for Python 2 -- which isn't installed by default anymore and a bit difficult to come by. But, after agonizingly converting Python 2-isms over to Python 3, you'll come to find out that that's not the only thing that's changed, a number of the tools (codesign and otool) don't output the same on ARM64 at which time you'll finally stumble across a kind soul that converted SMJobBless.py ... only to find out that it's not actually needed for this project?! Not sure if it's because the Launch Service is contained in the XPC and not the app, but either way - it seems to not be needed.
If you've run Privileges before, it'll have installed it's escalated helper, which will stand in the way of a local Xcode build copying itself over - which matters because of the aforementioned code signing. You'll need to clear away these artifacts
$ sudo rm -rf /Library/PrivilegedHelperTools/corp.sap.privileges.helper
$ sudo rm /Library/LaunchDaemons/corp.sap.privileges.helper.plist
Just deleting them isn't enough, it seems some sort of runtime launchd state needs to be wiped. It's unclear to me if some incantation of launchctl will clear this out, maybe an invocation of launchctl kickstart -k <foo> or something? I ended up rebooting and that seemed to do the trick anyway.
It seems like you need a particular signing certificate to allow the various signing validations that SMJobBless and the XPC communications are doing to be valid. Particularly, it seems you'll need a Developer ID Application, which happens to match what's encoded in the .xcodeproj pulled down from the GitHub repo. This means you can't enable Automatically manage signing as you won't get this type of certificate (as near as I can tell - please correct me if I'm wrong).
Once you've got all that sorted, since you aren't signing with the SAP developer's certificate, your certificate will have a different unique Team ID, so you'll need to update SMAuthorizedClients and SMPrivilegedExecutables, respectively, (look for 7R5ZEU67FQ and replace with your team ID) in
PrivilegesHelper/PrivilegesHelper-Info.plist
PrivilegesXPC/Info.plist
I think that's basically got it. Hope that helps someone else
I'm not sure if this is the right place to ask this question:
I am trying to run a prolog file, that uses the prolog-library delay. So it has at some place in the beginning the following line:
:- use_module(library(delay)).
When starting that file, Prolog tells me
source_link `library(delay)` does not exist
Goal (directive) failed: atoms:use_module(library(delay))
So I thought, maybe I need to install that library manually, first. So I ran ?- pack_install(delay)
But that returned
% Contacting server at http://www.swi-prolog.org/pack/query ...
ERROR: SSL(14090086) ssl3_get_server_certificate: certificate verify failed
I have no idea how to proceed and google is not helping...
This is a problem connecting to the server offering the package.
It actually works for me:
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
Install delay#0.3.3 from http://storage.googleapis.com/packs.ndrix.com/delay/delay-0.3.3.zip Y/n?
What is your Prolog version?
Can you download the pack directly. Either using the browser or wget/curl:
wget http://storage.googleapis.com/packs.ndrix.com/delay/delay-0.3.3.zip
The above is a zipfile of the repository https://github.com/mndrix/delay/
I suppose you can just put file delay/prolog/delay.pl onto the Prolog library search path.
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.
[2]> (ql:quickload "cl+ssl")
To load "cl+ssl":
Load 1 ASDF system:
cl+ssl
; Loading "cl+ssl"
*** - Unable to load any of the alternatives:
("libssl32.dll" "ssleay32.dll")
After three days of banging my head against the wall, I'm asking my first question on stack overflow. And with any luck it won't get deleted, and with heaps more there will be a solution.
While trying to install Humbler via quicklisp, CL+SSL (one of several dependencies) complained of being "Unable to load any of the alternatives: (libss132.dll "ssleay32.dll")
I soon learned that I had to install the OpenSSL dlls, easily enough done. I also learned I may have to point CFFI in the direction of my dlls, and that I had to be sure to get the 64 bit versions. But that error has persisted.
Using Clisp 2.47 on Win 7 64
Things I have tried already:
Installing open ssl dlls
Installing VS 2008 Redist
Putting those dlls in system32
Putting them in the same folder as the Clisp .exe
Putting them in in the installation folder created by OpenSSL
Pointing to the exact location of each individual dll using "use another library instead" restart
Pushing various locations to the CFFI:Foreign-Library-Directories list
Break 1 CL+SSL[3]> :R2
Enter a new value (unevaluated): ("C:\OpenSSL-Win64\libssl32.dll")
*** - Unable to load foreign library (LIBSSL32.DLL-8079).
FFI:OPEN-FOREIGN-LIBRARY: Cannot open library "C:\OpenSSL-Win64\libssl32.dll"
Uninstalling and then installing all the different OpenSSL builds
available Running Clisp as an administrator Deleting Quicklisp's
cache of CL+SSL Doing all of the above steps in SBCL and Lispworks
Turning it off and on again
I've never asked a question on stack overflow before. Then again I've never spent three days trying to get a dependency to load. Please help before I have a stroke.
It turns out I did need the 32 bit version of OpenSSL v 1.0.1
I guess the bit depth of the compiler reigns supreme. Sounds obvious in retrospect.
This error arose while I was trying to deploy to aws. It turns out this is an issue on my machine that others are no experiencing.
jkazil#jlk:~/Projects/code/geoq-chef-repo [git master] $ vagrant up --provider=aws
Bringing machine 'default' up with 'aws' provider...
[default] Box 'ubuntu_aws' was not found. Fetching box from specified URL for
the provider 'aws'. Note that if the URL does not have
a box for this provider, you should interrupt Vagrant now and add
the box yourself. Otherwise Vagrant will attempt to download the
full box prior to discovering this error.
Downloading or copying the box...
An error occurred while executing multiple actions in parallel.
Any errors that occurred are shown below.
An error occurred while executing the action on the 'default'
machine. Please handle this error then try again:
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
jlk:~/Projects/code/geoq-chef-repo [git master] $
I found a couple of things on the internets that said I should look at my version of openssl. At first, it was 0.9.8, but I had 1.0.1f in homebrew. So I found this: Update OpenSSL on OS X with Homebrew and followed it. And I was was able to update OpenSSL.
jkazil#jlk:~/Projects/code/geoq-chef-repo [git master] $ openssl version
OpenSSL 1.0.1f 6 Jan 2014
jlk:~/Projects/code/geoq-chef-repo [git master] $
But that didn't fix the issue. Just to clarify, this is not an aws issue, but an me issue. Here is me trying to pull a machine down locally. I am using the insecure flag to try to push it through, but it didn't work with or without.
jkazil#jlk:~/Projects/code/geoq-chef-repo [git master] $ vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box --insecure
Downloading or copying the box...
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
jlk:~/Projects/code/geoq-chef-repo [git master] $
Lastly, I wanted to share my PATH, just in case someone had that question.
jlk:~/Projects/code/geoq-chef-repo [git master] $ echo $PATH
/usr/local/Cellar/ruby/2.0.0-p247/bin:/Users/jkazil/bin:/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
jlk:~/Projects/code/geoq-chef-repo [git master] $
Any suggestions?
This is going to be sad answer, but the resolution to this was to update to 10.9. Then the problem went away. I know that this is not the answer that people want to here, but I thought I would try after banging my head against the wall for awhile.
Thank you everyone for your help!
P.S. VAGRANT_LOG=info was help also in getting set up.
I found a couple of things on the internets that said I should look at my version
of openssl. At first, it was 0.9.8, but I had 1.0.1f in homebrew. So I found this:
OpenSSL Version MacOSX Homebrew and followed it. And I was was able to update OpenSSL.
Mac OS X will do as much as it can to load 0.9.8 in /usr/lib:
$ find /usr/ -iname libssl*
/usr//lib/libssl.0.9.7.dylib
/usr//lib/libssl.0.9.8.dylib
/usr//lib/libssl.dylib
You will need to ensure you are loading the expected version of OpenSSL. If you can get it under gdb, issue info shared and see what version of OpenSSL actually loaded.
A few things about OS X and its linker: (1) it ignores rpath's; (2) it ignores requests like -Bstatic; (3) more generally, it always links to the shared object if available (even on iOS where the only thing you are suppose to use is an archive); (4) LD_PRELOAD is not honored.
You might have some luck with using DYLD_LIBRARY_PATH.
If you can't get OS X to use 1.0.1f, then you will have to re-build the components in question. But instead of specifying -L/usr/local/ssl -lssl -lcrypto, you will need to omit the flags and specify the full archive like /usr/local/ssl/lib/libssl.a (without the -l).
Don't buy into the claims you don't have to do these things on OS X (claims like "use -L and -lssl because that's what your suppose to use"). I suffered them for years on Apple's gear, and I know for certain it does not work (and the people making the claims apparently don't use OS X). OS X is a real bastard at times.
One cause for this error could be an old version of OpenSSL trying to connect to a server which uses HTTPS with SNI:
http://sourceforge.net/p/curl/bugs/1037/?limit=10&page=1#aa7f
Try setting the log level higher (e.g. VAGRANT_LOG=debug vagrant up – see the Vagrant debugging guide) to see the URL in question and test it by hand using curl to confirm the failure.