Attacking PowerShell Clixml Deserialization
(truesec.com)50 points by and3x 2 months ago | 17 comments
50 points by and3x 2 months ago | 17 comments
Joker_vD 2 months ago | root | parent | next |
Eh, I wouldn't really call it "basic input validation", it's more like fuzzy presumptions of trustworthiness. You have one part of PowerShell team that is wary of deserializing ScriptBlocks into ScriptBlocks instead of strings because that could trivially lead to RCE; and then there is other part which sees nothing wrong with executing code with arbitrary semantics (e.g. Get-ItemProperty) on whatever strings are lying around in the blob.
The root of the problem is IMHO is having code with arbitrary semantics; it's undoubtedly quite handy to use but the price is the inherent uncertainty about the security implications. I mean, who is aware that if you feed Get-ItemProperty something that starts with two backslashes, then it will blindly send your credentials to whatever domain is written after those backslashes? Why is it even doing that? Oh, right, because that's how you make remote shares look like local directories.
a1a 2 months ago | root | parent |
I didn't mean to trivialize the issue. You describe a problem that arise when multiple parties share data with "presumptions of trustworthiness" i.e. do not perform proper input validation. No?
Joker_vD 2 months ago | root | parent |
Well, I guess you can put it like that but I personally wouldn't call it "basic input validation", that would be something on the level "does this field really contains an integer?"
I don't think the problem is even the Get-ItemProperty itself, even though you'd probably want to use Select-Object instead wherever you can, but the fact that deserializer allows ridiculous PSPath values in the nested objects/properties; why does it do it? Is there no actual schema for e.g. Microsoft.Win32.RegistryKey type?
mdaniel 2 months ago | root | parent | prev | next |
> I am amazed that it's 2024 and we still have problems with basic input validation.
https://news.ycombinator.com/item?id=41392128 :rolling-eyes:
xbar 2 months ago | root | parent | prev |
I envy your wonder. I predict amazement for decades to come.
2 months ago | root | parent |
kojiphilippines 2 months ago | prev | next |
The thing I love about powershell is that you don't have to learn any DSLs, unlike bash, zsh, and the like. Want to manipulate some structured text data? Convert it to a native object, modify it using powershell syntax, and convert it back to the original data format. If you want to do this in bash, you have to learn the syntax and parameters for many utilities like jq, awk, starletxml, and many others. Also, unlike bash, you can use the output of commands like ls directly without worrying that some characters might break your code, as is the case with bash/zsh. You can also easily create whole UI windows in PowerShell and do some other complicated things that are barely possible in bash. Some people complain that cmdlets are too long to write, but you can just write the first letters of each command, e.g. Get-ChildItem -> gci, and it will do the work. Also, everything is much more standardized than in bash, which makes it easier to learn the scripting language.
poincaredisk 2 months ago | root | parent | next |
>you don't have to learn any DSLs, unlike bash, zsh, and the like.
I'm not sure I follow. Surely you need to learn PowerShell. What other DSL do you need to learn to use bash?
If you mean, for example, grep syntax: primary use case of a shell is running shell commands, you need to know regex to search using PowerShell too.
I agree that powershell is a better programming language than bash, but I don't really write programs in bash (or fish, which I primarily use). And for serious scripts I prefer Python anyway
>Also, unlike bash, you can use the output of commands like ls directly without worrying that some characters might break your code,
Actually, unlike bash, you can't use the output of arbitrary command. In bash, everything is a text that you can prices generically, grep, less, tail, etc. Unlike in powershell.
stackskipton 2 months ago | root | parent | next |
Generally other DSLs are other applications you will need with bash to accomplish your goal like grep, curl, jq and others. For example, to hit a rest API, parse the response and then do something based on the response in bash would require curl, jq to properly handle it. Powershell wouldn't require that since Invoke-RestMethod would return dictionary that easily handled. Also, for applications that can return JSON like kubectl, it can easily turn those into objects with ConvertFrom-JSON
Think of Powershell as replacement for bash AND python with built in CLI library. You can run interactively to do little stuff but if you need heavier lifts that requires a script with prompts and all that, you got it.
pwshthrowaway 2 months ago | root | parent | prev |
Nothing stopping you from using PowerShell like that with regular expressions and string manipulations like Select-String, Out-String, -Split.
leni536 2 months ago | root | parent | prev | next |
It might compare favorably as a scripting language to bash, but I prefer python in this space.
As an interactive shell I'm getting used to powershell on Windows, but I have too much bash muscle memory for now.
adzm 2 months ago | root | parent | prev | next |
My biggest frustration is remembering to use LiteralPath so filenames with [] in them don't cause trouble
netmare 2 months ago | root | parent | next |
I had the same problem initially. It's sometimes easier on the command line, since piping file and directory objects to commands generally binds their PSPath to LiteralPath using a parameter alias.
2 months ago | root | parent | prev |
2 months ago | root | parent | prev |
24currynigger 2 months ago | prev |
[flagged]
a1a 2 months ago | next |
Wow, this is a Hyper-V breakout! I am amazed that it's 2024 and we still have problems with basic input validation.