<p>악의적 인 데이터가있는 numpy로드 기능으로 인해 명령이 실행됩니다.</p>

버전 <= 1.16.0, 작동 함

예, 이것이 np.load(allow_pickle=True) 이 추가 된 이유입니다. 이제 기본값 인 False 하고 잘 읽을 수있는 메시지를 제공 할 수있을 것 같습니다. "use allow_pickle="True" 이 파일을 신뢰하십시오 ".

나는 이것이 더 나은 기본값이라는 데 동의하므로 불행히도 모든 과학자들이 실험실에서 일부 데이터를 공유 (또는 그냥 저장 / 다시로드)하는 것과 같이 약간 시끄러운 경우에도 지원 중단을 추진할 수 있습니다.

그래서 allow_pickle 는 2015 년 4 월에 추가되었으므로 numpy 1.10부터 존재 했어야 할 것 같습니다. 따라서 1.17을 사용 / 지원하는 많은 사람들이 여전히 1.10 (kwarg을 지원하거나 지원하지 않는 고통을 제거함)을 지원할 것이라고 의심하기 때문에 움직임이 더 현실적이라고 생각합니다. 현재로서는 scipy가 버전 1에서 여전히 1.8을 지원하는 것 같습니다.

오래 지속될 것 같아

원활한 전환을 원하면 사용 중단 경고를 기록하고 날짜를 제공하는 것이 좋습니다.

@Plazmaz 는 물론 일반 사용자가 작업을 중단하기를 원한다면 VisibleDeprecationWarning을 사용합니다. 그런 다음 하나 또는 두 번의 릴리스 후에 지원 중단하십시오. 문제는 필요한 경우 해결하는 것이 귀찮고 일부 이전 버전에는 kwarg가 존재하지 않는다는 것입니다. 경고를 피하고 둘 다 지원하려면 if np.__version__ > ...: use kwarg else do not use kwarg 를 수행해야하기 때문입니다.

어쨌든 1.17에 들어갈 수있는 좋은 기회가 있다고 생각합니다. 따라서 PR이 열려 있다고 느끼지만 누군가가 불평하는지 확인하기 위해 메일 링리스트를 핑 (ping) 할 수 있습니다.

안녕하세요, Fedora numpy RPM 관리자입니다. 배포판 패키징에서 이것을 완화하는 좋은 방법은 무엇입니까?

나는 좋은 방법을 모른다. 우려 수준에 따라 조만간 경고를 추가 할 예정이므로 1.17에 확실히 있습니다. 누군가가 극도로 염려하는 경우 백 포팅 또는 더 빨리 이동하는 것에 대해 논의 할 수 있지만 이는 다운 스트림이 이에 의존하는지 여부에 따라 크게 달라집니다.

나는 이것을 위해 노력 하고있다.

cc @jeanqasaur re : 보안 / 취약성 전문성

안녕하세요, Fedora numpy RPM 관리자입니다. 배포판 패키징에서 이것을 완화하는 좋은 방법은 무엇입니까?

@limburgher : 페도라는 파이썬에 내장 된 똑같은 기능에 대해 무엇을합니까? 이것이 완화가 필요한 것인지는 분명하지 않습니다.

기본값을 변경하는 것을 반대하지는 않지만 이것을 취약점으로 선언하는 것은 잘못된 것 같습니다. 문서화되고 설계된대로 작동합니다.

불행히도 규칙은 CVE 번호가 할당되면 더 이상 버그가 있는지 여부가 중요하지 않으며 배포판은 고객에게 가치를 제공하고 있음을 증명하기 위해 무언가 를 시도해야

save 및 load 동안 특정 파일이 피클을 사용하는지 여부를 알 수 있습니다. 그렇죠? 두 경우 모두 allow_pickle=False 로 마이그레이션하는 것이 좋을 것입니다. save 또는 load 실제로 필요한 경우에 정확히 어떤 종류의 지원 중단 경고를 발행하는 중간 기간을 두십시오. 피클을 사용하고 allow_pickle 가 지정되지 않았습니다.

@ eric-wieser stdlib 피클과의 차이점은 load / save 실제로 대부분의 경우 피클 사용을 피할 수 있다는 것입니다 (예 : 기본 유형의 간단한 배열). pickle은 객체 배열이나 IIRC 특정 복잡한 dtype과 같은 더 이국적인 경우에만 사용됩니다. 이렇게하면 대부분 안전 케이스를 사용하는 사람들이 문서를 충분히 자세히 읽지 않으면 안전하지 않은 케이스가 존재한다는 사실을 놓칠 수 있습니다. 어쨌든 "안전 모드"와 "안전하지 않은 모드"가 모두있는 경우 "안전 모드"를 기본값으로 사용하는 것이 좋습니다. stdlib pickle OTOH의 경우 항상 100 % 안전하지 않으므로 기본값에 대해 걱정할 필요가 없습니다.

솔직히 문서화 된 의도적 인 기능이라면 특히 안전이 기본값 인 경우 양심적으로 BZ를 닫을 수 있습니다. 저는 우리가 파이썬의 기능을 어떻게 처리하는지 모르겠습니다. 내가 볼게.

사양을 살펴보면 그 점에서 업스트림에서 아무것도 변경하지 않는다고 생각합니다.

CVE에 대해 이의가 제기 되었습니까? 그러면 관리자에게 시나리오가 더 명확해질 수 있습니다.

CVE는 대체로 가짜로 보입니다. numpy.load 가 임의의 코드를 실행할 수 있다는 것은 잘 알려져 있고 문서화되어 있으며 직렬화 된 Python 객체 배열을로드하는 데 필요합니다. 사용자는이 라이브러리 함수에 allow_pickle=False 를 전달하여 객체 배열로드를 금지 할 수 있습니다.

기본값이 명시 적으로 요청되었을 때만 객체 배열을로드하는 것이 더 좋았을 것이지만 역사적 이유 때문입니다. 전환은 이전에도 제안되었으며, 위의 논의는 이전 버전과의 호환성을 통제 할 수 없게 깨지 않는 방식으로 전환하는 방법에 대한 것입니다.

그러나 Python 피클 링과 유사하게 numpy.load 부주의하게 사용하면 다운 스트림 애플리케이션에 취약성이 발생할 수 있습니다.

numpy.load 가 임의의 코드를 실행할 수 있다는 것은 잘 알려져 있고 문서화되어 있으며 직렬화 된 Python 객체 배열을로드하는 데 필요합니다.

나는 그것이 문서화되었다고 말하고 싶습니다. 저는 몇 년 동안 numpy를 사용해 왔지만 numpy.save / numpy.load 의 빈번한 사용자는 아니지만 numpy.load 에 대해 전혀 분명하지 않았습니다. pickle 와 동일한 취약점이 있습니다. 물론 나는 numpy.load 가 pickle 사용할 수 있다는 것을 몰랐습니다 (나는 numpy-native 배열만을 사용하고 @njsmith가 언급 한 시나리오와 정확히 일치하는 생각을하지 않았습니다).

pickle 이 취약하다는 사실은 잘 알려져 있으며, 문서에는 상단에 큰 빨간색 경고가 있습니다.

경고 : pickle 모듈은 오류가 있거나 악의적으로 구성된 데이터에 대해 안전하지 않습니다. 신뢰할 수 없거나 인증되지 않은 소스에서받은 데이터를 절대로 피클하지 마십시오.

이에 비해 numpy.load 의 문서 는 allow_pickle 키워드에 대한 설명에서 전체 보안 측면

allow_pickle : _bool, optional_
npy 파일에 저장된 피클 된 객체 배열을로드 할 수 있습니다. 피클을 허용하지 않는 이유에는 피클 된 데이터를로드하면 임의 코드가 실행될 수 있으므로 보안이 포함됩니다. 피클이 허용되지 않으면 객체 배열로드가 실패합니다. 기본값 : True

적어도 allow_pickle=False 이 기본값이 될 때까지 numpy.load 의 문서에 Big Red Warning을 넣을 수 있다면 싫어하지 않을 것입니다. 변화가보고 될 때까지 numpy.load 하나의 마음한다는 점에서 같은 붉은 깃발을 제기한다 pickle.load 발생시킵니다.

numpy.load 대한 문서 PR 환영

이제 문서 에 피클에 대한 경고가 있습니다.

불행히도 규칙은 CVE 번호가 할당되면 더 이상 버그가 있는지 여부가 중요하지 않으며 배포판은 고객에게 가치를 제공하고 있음을 증명하기 위해 _ 무언가 _ 시도해야합니다. 그것이 무엇인지는 확실하지 않지만, 회사와 운영진은 지속적으로 넘쳐나는 취약성을 관리하기 위해 항상 고군분투하고 있으며,이를 수행하는 데 사용하는 도구는 뉘앙스를 전달할 여지가 많지 않습니다. 간다.

@njsmith 는 그렇게 나쁘지 않습니다 . numpy.load 기본값을 allow_pickle ~ False 로 설정합니다. 실제로 완전히 어리석은 생각은 아닙니다.

내가 볼 수있는 유일한 위험은 allow_pickle을 명시 적으로 설정하지 않은 모든 프로젝트가 중단된다는 것입니다.

그것은 단지 최종 사용자 아니에요 프로젝트 우리에 대해 걱정할 필요가 - 내가 제공하는 다운 스트림 라이브러리 걱정 mylib.load 랩이 np.load . 객체 배열을로드하지 못합니다. 다음 세 가지 중 하나가 발생합니다.

• 그들은 버려진 상태로 남아 있으며 예전 방식으로 객체 배열에서 작동하지 않습니다. 사용자는 자신의 데이터가 인질로 잡혀 있음을 발견하고이를 복구하기 위해 numpy를 다운 그레이드해야합니다.
• 그들은 이전 동작을 재개하기 위해 allow_pickle=True 설정을 다시 릴리스합니다. 즉, 다운 스트림 라이브러리는 이것이 그들이 신경 쓰는 공격 벡터가 아니라고 생각한다는 것을 나타냅니다. 여전히 호환되지 않는 릴리스 비용이 발생합니다.
• 그들은 자신의 API에 allow_pickle=False 를 노출하여 문제를 다운 스트림으로 푸시합니다.

내 선호는 다음과 같습니다.

• np.save 아무것도하지 않습니다. 객체 배열을 저장하는 동안 마지막에 장기 실행 스크립트 충돌이 발생하는 것은 끔찍한 경험입니다.
• np.load 의 기본값을 None 합니다. True 또는 False 명시 적으로 전달하지 않는 사용자를 감지하고 보안 ( False )과 객체 중에서 선택하도록 요청하는 위험을 설명하는 UserWarning 를 내 보냅니다. 배열 지원 ( True ). 이 경고를 내 보낸 후 기본적으로 현재 상태를 유지합니다. 여기서 문제는 인식 부족이라는 것을 이해합니다. 두 가지 선택 모두 모든 경우에 옳은 것은 아니므로 경고없이 기본값에 대해 갑자기 마음을 바꿔야한다고 생각하지 않습니다.

@ eric-wieser 스크립트 충돌의 고통에 대한 좋은 지적. 나는 기본적으로 UserWarning 를 제공 할 것입니다.

문제는 우리가 장기적으로 load 에서 무엇을하고 싶은지입니다. 어레이가 안전 할 때 모든 사람에게 kwarg (경고를 무음)를 사용하도록 강요하는 것을 좋아하지 않습니다. 데이터에서 누군가를 잠글 위험이 없다는 장점이 있지만 ... OTOH, 경고가 "안전하지 않은"로드에만 표시되면 너무 늦을 수 있습니다. 지금은 전환 기간을 조금 더 길게 만드는 편이 약간 선호되는 것 같습니다.

OTOH, 경고가 "안전하지 않은"부하에만 표시되면 너무 늦을 수 있습니다.

어느 한 쪽:

• 라이브러리 / 스크립트가 이미 존재하고 게시되었습니다. 우리가하는 일은 이미 너무 늦었습니다.
• 라이브러리 / 스크립트는 아직 개발 중입니다. 개발자는 안전한 파일에 대한 로컬 테스트 중에 경고를 확인하고 원하는 동작에 대해 정보에 입각 한 결정을 내릴 수 있어야합니다. 이러한 이유로 배열이 안전하더라도 (그리고로드하기 전에 -Werror 해당하는 python이있는 경우) 경고를 표시해야합니다.

네, 저는 확실히 라이브러리에 동의하지만 방대한 수의 짧은 스크립트에 대해서는 약간 성가 시다고 생각합니다.

np.load 의 기본값을 None 합니다. True 또는 False 명시 적으로 전달하지 않는 사용자를 감지하고 보안 ( False )과 개체 중에서 선택하도록 요청하는 위험을 설명하는 UserWarning 를 내 보냅니다. 배열 지원 ( True ). 이 경고를 내 보낸 후 기본적으로 현재 상태를 유지합니다. 여기서 문제는 인식 부족이라는 것을 이해합니다. 두 가지 선택 모두 모든 경우에 옳은 것은 아니므로 경고없이 기본값에 대해 갑자기 마음을 바꿔야한다고 생각하지 않습니다.

이것은 매우 성가신 것 같습니다. 대부분의 사람들은 (내 생각에) 객체 배열을 저장 /로드하지 않습니다. 그리고 누군가가 경고를 놓친 경우 최악의 경우는 (결국)로드 할 때 스크립트가 충돌하고 데이터는 여전히 디스크에 안전하며 allow_pickle 플래그로 재 시도합니다.

먼저 안전하게로드를 시도하고 객체 배열로 인해 실패한 경우에만 외치는 것은 numpy의 책임을 넘어서입니까? 그것은 대부분의 (객관적이지 않은) 사용 사례에 대한 추가 작업을 제거하지만 전체 보안 문제에 대한 가시성을 감소시킬 것이라고 생각합니다. 그리고 여기서도 "사용자가주의를 기울여야한다"고 "사용자에게 불편을 끼쳐서는 안된다"는 것은 약간 모순적인 노력이라고 생각합니다.

* Change the default in `np.load` to `None`. Detect the user not passing in `True` or `False` explicitly, and emit a `UserWarning` explaining the dangers, asking them to choose between security (`False`) and object array support (`True`). Default to the status quo after emitting this warning. It's my understanding that the problem here is lack of awareness. Neither choice is correct in all cases, so I don't think we should suddenly change our minds about the default without warning.

이 패치는 어떻습니까?

* Change the default in `np.load` to `None`. Detect the user not passing in `True` or `False` explicitly, and emit a `UserWarning` explaining the dangers, asking them to choose between security (`False`) and object array support (`True`). Default to the status quo after emitting this warning. It's my understanding that the problem here is lack of awareness. Neither choice is correct in all cases, so I don't think we should suddenly change our minds about the default without warning.

이 패치는 어떻습니까?

--- a/numpy/lib/npyio.py
+++ b/numpy/lib/npyio.py
@@ -265,7 +265,7 @@ class NpzFile(object):
         return self.files.__contains__(key)


-def load(file, mmap_mode=None, allow_pickle=True, fix_imports=True,
+def load(file, mmap_mode=None, allow_pickle=None, fix_imports=True,
          encoding='ASCII'):
     """
     Load arrays or pickled objects from ``.npy``, ``.npz`` or pickled files.
@@ -367,6 +367,16 @@ def load(file, mmap_mode=None, allow_pic
     memmap([4, 5, 6])

     """
+
+    if allow_pickle is None:
+        UserWarning("""
+        numpy.load() run without explicit setting allow_pickle option.
+        If you are not completely certain about security of the pickled
+        data, you are strongly encouraged to set allow_pickle to False,
+        otherwise you can set it to True.
+        """)
+        allow_pickle = False
+
     own_fid = False
     if isinstance(file, basestring):
         fid = open(file, "rb")

나는 여전히 객체 데이터를로드 할 때 경고에 찬성합니다. 약간 "너무 늦을 수 있습니다". 저장할 때 경고를 추가 할 수 있습니다 (영구적 경고 만 해당). 내가 더 그런 것으로 변모하기를 바라는 공개 PR이있다. 시간을 보내고 싶다면 일반적으로 PR에 만족합니다.
어쨌든 곧 사용 중단주기를 시작하는 것으로 전환되는 것으로 보이며, 그렇게 될 것이라고 생각합니다 (그러나 누군가가 그것을 선택하면 더 빨라질 것입니다;)). 요청이 지연 될 가능성이 적지 만 의심스럽고 시도하지 않고는 알기 어렵습니다.

이 문제는 https://nvd.nist.gov/vuln/detail/CVE-2019-6446에 언급되어 있으므로 nexus iq가 여전히 취약하다고 간주하므로이 문제를 닫아 주시겠습니까?

감사합니다 @ Manjunath07