Evil-WinRM - OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error #3593

D3vil0p3r · 2022-11-22T19:54:12Z

I have searched open and closed issues for duplicates
I am submitting a bug report for existing functionality that does not work as intended

Bug description

When evil-winrm tool from BlackArch repo is run, the following output is generated:

evil-winrm -u Jareth -p sarah -i 10.10.79.152

Evil-WinRM shell v3.4

Info: Establishing connection to remote endpoint

Error: An error of type OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error

Error: Exiting with code 1

Furthermore, each time evil-winrm is run, this git warning is produced:

evil-winrm -h            
fatal: not a git repository (or any of the parent directories): .git

<SNIP>

This issue occurs also in BlackArch after a Full Upgrade of the system.

In Debian-based OS, Evil-WinRM works correctly.

Steps to reproduce

By guessing Arch system has BlackArch repo available, run sudo pacman -Syyu
Run sudo pacman -Syy evil-winrm
Take a test machine where you can test Evil-WinRM, for example this TryHackMe machine: https://tryhackme.com/room/yearoftheowl
Run evil-winrm -u Jareth -p sarah -i 10.10.79.152

where 10.10.79.152 is the Target IP address. It will be different in your case.

Actual result: Describe here what happens after you run the steps above (i.e. the buggy behaviour)

The following output is produced:

Evil-WinRM shell v3.4

Info: Establishing connection to remote endpoint

Error: An error of type OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error

Error: Exiting with code 1

Furthermore, each time evil-winrm is run, this git warning is produced:

evil-winrm -h            
fatal: not a git repository (or any of the parent directories): .git

<SNIP>

Expected result: Describe here what should happen after you run the steps above (i.e. what would be the correct behaviour)

The following is the expected output:

Evil-WinRM shell v3.4

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\Jareth\Documents>

Screenshots

Info for developers

GNU/Linux distribution: Arch Linux
Tool version: 3.4 (latest)

Link to debug log

The text was updated successfully, but these errors were encountered:

noraj · 2022-11-23T23:25:02Z

Run sudo pacman -Syy evil-winrm

Don't do that, it's partial upgrade https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported

I'll take a look at EvilWinrm openssl issue and update it at the same time.

noraj · 2022-11-23T23:34:54Z

Also note evil-winrm is listed as broken in this issue #3519 (comment)

noraj · 2022-11-23T23:51:27Z

Furthermore, each time evil-winrm is run, this git warning is produced:
evil-winrm -h            
fatal: not a git repository (or any of the parent directories): .git

<SNIP>

I have fixed this issue in #3597 but I can't investigate on the OpenSSL error until #3519 is fixed

DF001 · 2022-11-24T10:38:21Z

@noraj issue has been fixed this morning go to /etc/ssl/openssl.cnf and under
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
add:
legacy = legacy_sect
so it shows as
[provider_sect]
default = default_sect
legacy = legacy_sect
than
search for
[default_sect]
#activate = 1
remove the # and under that line add
[legacy_sect]
activate = 1
save the file and evil-winrm will work again
Cause of issue. openssl was missing md4

D3vil0p3r · 2022-11-24T16:15:27Z

@noraj take note of this: https://bugs.archlinux.org/task/76653?project=1&order=dateopened&sort=desc

The user answering to the bug opened by @DF001 makes me understand that, since with OpenSSL 3 md4 is in the legacy provider which is not enabled by default, and if needed it must be set on the OpenSSL configuration file, is it meaning that for Evil-WinRM is it needed to create a dedicated OpenSSL config file dedicated for Evil-WinRM or that changes the existing OpenSSL config file by enabling the MD4 hashing algorithm?

noraj · 2022-11-24T20:00:04Z

It would be best it has a dedicated config file

D3vil0p3r · 2022-11-24T22:09:21Z

It would be best it has a dedicated config file

In your opinion, what is the best way for managing this? Inside the evil-winrm PKGBUILD or in a separated manner from evil-winrm (that could mean create and set manually a dedicated openssl config file)?

noraj · 2022-11-24T22:42:01Z

In your opinion, what is the best way for managing this? Inside the evil-winrm PKGBUILD or in a separated manner from evil-winrm (that could mean create and set manually a dedicated openssl config file)?

IDK openssl well, IDK if it can load a custom config file from a path.

D3vil0p3r · 2022-11-24T23:05:08Z

After the update of evil-winrm by sudo pacman -Syyu, I don't get that warning about .git but I get the following warning:

fatal: detected dubious ownership in repository at '/usr/share/evil-winrm'
To add an exception for this directory, call:

	git config --global --add safe.directory /usr/share/evil-winrm

I tried also to remove evil-winrm by pacman and remove /usr/share/evil-winrm folder and reinstall it but I get the same warning.

D3vil0p3r · 2023-02-05T12:19:55Z

Hey @noraj
about the warning above when Evil WinRM is run:

fatal: detected dubious ownership in repository at '/usr/share/evil-winrm'
To add an exception for this directory, call:

	git config --global --add safe.directory /usr/share/evil-winrm

how is it possible to solve it?

noraj · 2023-02-05T14:07:46Z

This is due to

blackarch/packages/evil-winrm/PKGBUILD

Line 40 in e58c627

cp -a --no-preserve=ownership .git "$pkgdir/usr/share/$pkgname/"

that was need to fix #3593 (comment)

You can try playing with safe.directory git option to see how we can integrate this in the PKGBUILD.

D3vil0p3r · 2023-02-05T14:27:27Z

This is due to

blackarch/packages/evil-winrm/PKGBUILD

Line 40 in e58c627

cp -a --no-preserve=ownership .git "$pkgdir/usr/share/$pkgname/"

that was need to fix #3593 (comment)
You can try playing with safe.directory git option to see how we can integrate this in the PKGBUILD.

I will try. I have only a question for you: is there a sense or a reason to keep .git folder in /usr/share/evil-winrm?
Answer: because .git is used in gemspec file.

D3vil0p3r · 2023-02-05T15:26:21Z

@noraj by my tests, if git config --global --add safe.directory /usr/share/evil-winrm is added in package() function of the PKGBUILD, it works and it is run as the current user. The problem is that you cannot manage automatically the removal of safe.directory variable when the package is uninstalled.

The best idea should be to add git config --global --add safe.directory /usr/share/evil-winrm in the .install script file because in this manner is possible also to remove safe.directory variable when the package is uninstalled by git config --global --unset safe.directory /usr/share/evil-winrm. The problem of this approach is that, unlike the package() function in PKGBUILD, the .install script is run as root instead of the current user installing the package, so the safe.directory variable will be set only for the root user, and not for the current user, so if the current user calls evil-winrm command, it will get always that warning.

I need to understand if the .install script can be run as the current user that is installing the package.

D3vil0p3r · 2023-02-05T16:23:59Z

According to my last tests, this is my working proposal that manages also cases of reinstallation of the package and prevent multiple safe.directory variable to be set on git. My idea is applied only to the .install file and it applies on all users and has the following code:

post_install() {
  set -e
  cd /usr/share/evil-winrm
  rm -f Gemfile.lock
  bundle config build.nokogiri --use-system-libraries
  bundle config set --local path 'vendor/bundle'
  bundle install
  if ! git config --system --get safe.directory /usr/share/evil-winrm; then
      git config --system --add safe.directory /usr/share/evil-winrm
  fi
}

post_upgrade() {
  post_install "$@"
}

post_remove() {
   echo "Uninstalling Evil WinRM..."
   if git config --system --get safe.directory /usr/share/evil-winrm; then
      git config --system --unset-all safe.directory /usr/share/evil-winrm
   fi
}

@noraj if you agree, we can use this approach and I will create a Pull Request. Tested on an environment with two different standard users and works correctly.

noraj · 2023-02-05T17:59:16Z

Does it work with --local who set the option in .git/ and not on a per user basis? So maybe this way an .install file wouldn't be required.

D3vil0p3r · 2023-02-05T18:03:17Z

By that approach, how do you manage the removal of safe.directory when evil-winrm will be uninstalled?

noraj · 2023-02-05T18:57:41Z

By that approach, how do you manage the removal of safe.directory when evil-winrm will be uninstalled?

Since it will only set stuff in .git/, the removal of /usr/share/evil-winrm/ when performing pacman -R would get rid of it. But I'm not sure this option works locally.

D3vil0p3r · 2023-02-05T19:33:48Z

By that approach, how do you manage the removal of safe.directory when evil-winrm will be uninstalled?

Since it will only set stuff in .git/, the removal of /usr/share/evil-winrm/ when performing pacman -R would get rid of it. But I'm not sure this option works locally.

I tested it but when I run evil-winrm I still get that warning message despite the variable has been added in /usr/share/win-rm/.git/config as:

[safe]
	directory = /usr/share/evil-winrm

soufian2017 · 2023-11-02T11:09:41Z

A working patch for the /etc/ssl/openssl.cnf file would be this
openssl/openssl#21247 (comment)

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

D3vil0p3r added the type::bug Valid bug label Nov 22, 2022

noraj self-assigned this Nov 23, 2022

noraj mentioned this issue Nov 24, 2022

evil-winrm: build fixes #3597

Merged

noptrix closed this as completed in #3597 Nov 24, 2022

This was referenced Dec 4, 2022

evil-winrm: fix OpenSSL 3 error #3620

Closed

[OpenSSL 3.0 Support] - Current WinRM version does not support the latest OpenSSL version WinRb/WinRM#340

Open

ultiMEIGHT mentioned this issue Feb 17, 2023

using evil-winrm - Error: OpenSSL::Digest::DigestError #3716

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Evil-WinRM - OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error #3593

Evil-WinRM - OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error #3593

D3vil0p3r commented Nov 22, 2022 •

edited

noraj commented Nov 23, 2022

noraj commented Nov 23, 2022

noraj commented Nov 23, 2022

DF001 commented Nov 24, 2022

D3vil0p3r commented Nov 24, 2022 •

edited

noraj commented Nov 24, 2022

D3vil0p3r commented Nov 24, 2022

noraj commented Nov 24, 2022

D3vil0p3r commented Nov 24, 2022

D3vil0p3r commented Feb 5, 2023

noraj commented Feb 5, 2023

D3vil0p3r commented Feb 5, 2023 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited

noraj commented Feb 5, 2023 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited

noraj commented Feb 5, 2023

D3vil0p3r commented Feb 5, 2023

soufian2017 commented Nov 2, 2023

Evil-WinRM - OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error #3593

Evil-WinRM - OpenSSL::Digest::DigestError happened, message is Digest initialization failed: initialization error #3593

Comments

D3vil0p3r commented Nov 22, 2022 • edited

Bug description

Steps to reproduce

Screenshots

Info for developers

Link to debug log

noraj commented Nov 23, 2022

noraj commented Nov 23, 2022

noraj commented Nov 23, 2022

DF001 commented Nov 24, 2022

D3vil0p3r commented Nov 24, 2022 • edited

noraj commented Nov 24, 2022

D3vil0p3r commented Nov 24, 2022

noraj commented Nov 24, 2022

D3vil0p3r commented Nov 24, 2022

D3vil0p3r commented Feb 5, 2023

noraj commented Feb 5, 2023

D3vil0p3r commented Feb 5, 2023 • edited

D3vil0p3r commented Feb 5, 2023 • edited

D3vil0p3r commented Feb 5, 2023 • edited

noraj commented Feb 5, 2023 • edited

D3vil0p3r commented Feb 5, 2023 • edited

noraj commented Feb 5, 2023

D3vil0p3r commented Feb 5, 2023

soufian2017 commented Nov 2, 2023

D3vil0p3r commented Nov 22, 2022 •

edited

D3vil0p3r commented Nov 24, 2022 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited

noraj commented Feb 5, 2023 •

edited

D3vil0p3r commented Feb 5, 2023 •

edited