哈希表漏洞(属性覆盖)? [英] Hash table vulnerability (property overwrite)?

问题描述

我在 PowerShell 中使用哈希表，我注意到一些与访问项目相关的奇怪行为.众所周知，PowerShell 允许至少三种不同的方式为哈希表条目赋值:

$hashtable["foo"] = "bar" #1$hashtable.Item("foo") = "bar" #2$hashtable.foo = "bar" #3

同时，我们使用#3语法来访问Hashtable对象本身的属性，例如Count、Keys、Values，等等.如果我们添加一个键与内部属性名称冲突的项目，PowerShell 允许我们这样做，并且我们实际上不再能够读取该属性的值(使用反射除外).

我猜在密钥来自不可信来源(例如来自外部文件或网络)的情况下，这可能会对流量控制产生不良影响，并且可能被恶意用户利用.

此代码段演示了该问题:

function Get-HashtableProperties($hashTable, $header){"{0} {1} {0}" -f ("-" * 10), $header"计数:{0}" -f $hashtable.Count"Keys.Count : {0}" -f $hashtable.Keys.Count"Values.Count : {0}" -f $hashtable.Values.Count实际计数(反射):{0}"-f $hashtable.GetType().GetProperty("Count").GetValue($hashtable)`nItems(键迭代):"$hashtable.Keys |ForEach-Object { " [ {0} = {1} ]" -f $_, $hashtable.Item($_) }`nItems(枚举器迭代):"$enumerator = $hashTable.GetEnumerator()while ($enumerator.MoveNext()){" [ {0} = {1} ]" -f $enumerator.Current.Key, $enumerator.Current.Value}}$fileContent = @"福 = 一个酒吧 = b"@$maliciousFileContent = @"福 = 一个酒吧 = b计数 = 0键 =值 ="@$hashtable = ConvertFrom-StringData $fileContent$damagedHashtable = ConvertFrom-StringData $maliciousFileContentGet-HashtableProperties $hashtable "普通哈希表"Get-HashtableProperties $damagedHashtable "损坏的哈希表"

输出:

---------普通哈希表 ----------数 : 2键数:2值.计数:2实际计数(反射):2项目(键迭代):[ 酒吧 = b ][ Foo = a ]项目(枚举器迭代):[ 酒吧 = b ][ Foo = a ]---------- 损坏的哈希表 ----------计数:0键数:1值.计数:1实际计数(反射):5项目(键迭代):[ = ]项目(枚举器迭代):[计数 = 0][ 酒吧 = b ][ Foo = a ][值=][ 键 = ]

问题:有没有办法防止这个问题，除了在分配之前手动检查每个键和/或当我们需要访问某些 的值时在代码中的任何地方使用反射哈希表属性?

解决方案

在这种情况下，您可以像这样访问 Hashtable 的 count 属性:

C:\PS>$ht = @{Count = 99}$ht.psbase.Count1

PowerShell 中的扩展类型系统通过这些 PS* 属性提供对象的多种不同视图.请参阅 PowerShell 团队博文了解详情.

I was playing around with hash tables in PowerShell, and I noticed some odd behavior related to accessing items. As we know, PowerShell allows at least three different ways of assigning values to hash table entries:

$hashtable["foo"] = "bar"        #1
$hashtable.Item("foo") = "bar"   #2
$hashtable.foo = "bar"           #3

Meanwhile, we use the #3 syntax to access the properties of the Hashtable object itself, such as Count, Keys, Values, etc. And if we add an item with the key that conflicts with the name of an internal property, PowerShell allows us to do so, and we effectively are no longer able to read the value of the property (except using Reflection).

I guess that in a situation where the keys come from an untrustworthy source (e.g. from external file or network), this might have an undesired impact on flow control, and could probably be exploited by a malicious user.

This snippet demonstrates the issue:

function Get-HashtableProperties($hashTable, $header)
{
    "{0} {1} {0}" -f ("-" * 10), $header

    "Count                      : {0}" -f $hashtable.Count
    "Keys.Count                 : {0}" -f $hashtable.Keys.Count
    "Values.Count               : {0}" -f $hashtable.Values.Count
    "Actual Count (Reflection)  : {0}" -f $hashtable.GetType().GetProperty("Count").GetValue($hashtable)

    "`nItems (Keys iteration):"
    $hashtable.Keys | ForEach-Object { "  [ {0} = {1} ]" -f $_, $hashtable.Item($_) }

    "`nItems (Enumerator iteration):"
    $enumerator = $hashTable.GetEnumerator()
    while ($enumerator.MoveNext())
    {
        "  [ {0} = {1} ]" -f $enumerator.Current.Key, $enumerator.Current.Value
    }
}

$fileContent = @"
    Foo = a
    Bar = b
"@

$maliciousFileContent = @"
    Foo = a
    Bar = b
    Count = 0
    Keys =
    Values =
"@

$hashtable = ConvertFrom-StringData $fileContent
$damagedHashtable = ConvertFrom-StringData $maliciousFileContent

Get-HashtableProperties $hashtable "Normal Hash Table"
Get-HashtableProperties $damagedHashtable "Damaged Hash Table"

Output:

---------- Normal Hash Table ----------
Count                      : 2
Keys.Count                 : 2
Values.Count               : 2
Actual Count (Reflection)  : 2

Items (Keys iteration):
  [ Bar = b ]
  [ Foo = a ]

Items (Enumerator iteration):
  [ Bar = b ]
  [ Foo = a ]
---------- Damaged Hash Table ----------
Count                      : 0
Keys.Count                 : 1
Values.Count               : 1
Actual Count (Reflection)  : 5

Items (Keys iteration):
  [  =  ]

Items (Enumerator iteration):
  [ Count = 0 ]
  [ Bar = b ]
  [ Foo = a ]
  [ Values =  ]
  [ Keys =  ]

Question: is there a way to protect against this issue, except manually checking every key before assignment and/or using Reflection everywhere in the code when we need to access the value of some Hashtable property?

解决方案

In this sort of a scenario you can access the Hashtable's count property like so:

C:\PS> $ht = @{Count = 99}
$ht.psbase.Count
1

The extended type system in PowerShell offers several different views on an object via these PS* properties. See the PowerShell team blog post for details.

这篇关于哈希表漏洞(属性覆盖)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！