¿Puede usar PtrToStringAuto para descifrar una cadena segura en Powershell 7 en macOS?

No he tenido éxito en obtener el siguiente fragmento de código para generar "¡Hola mundo!" en PS7

$string = $("Hello World!" | ConvertTo-SecureString -AsPlainText -Force)
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto(
[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($string))

El código anterior es un ejemplo de cómo descifrar una cadena segura sin especificar una longitud.

Este mismo código funciona en PS6 y PS5 para descifrar completamente Secure String, pero no funciona en PS7. La única forma de evitar esto que he encontrado es usar PtrToStringBSTR. Entonces funciona como se esperaba en todas las versiones de PS para este caso de uso.

Planteé un problema en el repositorio de Powershell en Github, pero no he recibido ninguna respuesta. Honestamente, solo estoy buscando alguna confirmación de que el comportamiento es el mismo para los demás.

https://github.com/PowerShell/PowerShell/issues/11953

Creo que algo como esto sería un cambio radical para una gran cantidad de código que se está portando a PS7.

Esto es lo que he encontrado hasta ahora:

Documentación

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.marshal.ptrtostringauto?view=netframework-4.8

Según la documentación, al especificar un número entero, PtrToStringAuto:

Allocates a managed String and copies the specified number of characters from a string stored in unmanaged memory into it.

Especificar un int de 11 devuelve "Hola", esto se debe a que todos los demás caracteres devueltos son nulos. En este caso, debe especificar un int de 23 para devolver la cadena completa "¡Hola mundo!" usando este método. He almacenado la salida en una variable para demostrar esto.

$String = $("Hello World!" | ConvertTo-SecureString -AsPlainText -Force) [System.Runtime.InteropServices.Marshal]::PtrToStringAuto( [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($string), 23)

$String[0] Returns H $String[1] Returns NULL
$String[2] Returns E $String[3] Returns NULL
etc.... 

Si no se especifica ningún entero, PtrToStringAuto:

Allocates a managed String and copies all characters up to the first null character from a string stored in unmanaged memory into it.

Creo que esto sugiere que Secure String se está almacenando con valores NULL, mientras que en PS6 no lo estaba, o que el comportamiento de la función PtrToStringAuto ha cambiado y ahora se adhiere al comportamiento que describe la documentación anteriormente.

Este es solo un problema en macOS; sin embargo, el uso de PtrToStringBSTR en lugar de PtrToStringAuto para descifrar Secure String funciona como se esperaba en Windows y macOS.

Esto parece relacionado: https://stackoverflow.com/a/11022662/4257163

Tampoco veo en ninguna parte que se haya realizado un cambio.

Tenga en cuenta que [securestring]se no se recomienda para el nuevo código más .

Mientras que en Windows las cadenas seguras ofrecen protección limitada , al almacenar la cadena encriptada en la memoria, a través de la DPAPI , y al acortar la ventana durante la cual la representación de texto sin formato se mantiene en la memoria, no se utiliza ningún cifrado en plataformas similares a Unix . ^[1]

La única forma de evitar esto que he encontrado es usar PtrToStringBSTR.

Que no sólo es una manera alrededor del problema, PtrToStringBSTRes el método que debería haber sido utilizado, para empezar , ya que la cadena de entrada es una BSTR. ^[2]

Tenga en cuenta que la conversión de una cadena segura hacia y desde una [string]instancia regular anula el propósito de usar [securestring]para empezar : terminará con una representación de texto sin formato de sus datos confidenciales en la memoria de su proceso cuya vida útil no puede controlar.

Si realmente desea hacer esto, un enfoque más simple y compatible con varias plataformas es:

[System.Net.NetworkCredential]::new('dummy', $string).Password

^{[1] Esto es especialmente problemático cuando guarda una cadena segura en un archivo , a través de ConvertFrom-SecureStringo Export-CliXml- vea esta respuesta .}

^{[2] El Autoen PtrToStringAuto()medios que el no administrado cadena de entrada se supone que utilizar una plataforma apropiada codificación de caracteres, mientras que BSTRes un (UTF-16) cadena "Unicode" en todas las plataformas. En Windows, se supone que una cadena no administrada tiene codificación UTF-16 (razón por la cual el código funciona), mientras que en plataformas similares a Unix es UTF-8 desde .NET Core 3.0 (PowerShell [Core] 7.0 se basa en .NET Core 3.1) , que explica sus síntomas: los NULcaracteres. en el BSTRcódigo UTF-16 de la instancia, las unidades se interpretan como caracteres por derecho propio cuando (mal) se interpretan como UTF-8. Tenga en cuenta que .NET Core 2.x (que es en lo que se basa PowerShell [Core] 6.x) (de manera inapropiada) predeterminado en UTF-16 , que este PR solucionó , lo que equivale a un cambio importante.}