Python: server_url_validator allows Azure WireServer (168.63.129.16) and IPv6-embedded IPv4 forms (NAT64/6to4/Teredo)
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 55/100
Hướng nghiên cứu
Bắt đầu trong semantic_kernel.connectors.openapi_plugin.server_url_validator tại validate_server_url, sau đó kiểm tra try_categorize_non_public_address và các helper phân loại IPv4/IPv6. Sử dụng các địa chỉ tái hiện và hành vi mong đợi trong issue làm các bước kiểm tra; công việc được coi là hoàn tất khi Azure WireServer bị chặn và các dạng NAT64, 6to4, Teredo được giải mã trước khi phân loại.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug
server_url_validator is the default SSRF guard for OpenAPI plugin calls (allow_private_network_access defaults to False), and it classifies IPv4 by explicit octet ranges and IPv6 by a short list of properties. Two categories fall outside both:
168.63.129.16— Azure's WireServer / platform channel, reachable from every Azure VM. It's a publicly routable address, so none of the_try_classify_ipv4branches match it.- IPv6 addresses that carry an IPv4 target inside them.
_try_classify_ipv6unwraps::ffff:viaipv4_mapped, but NAT64, 6to4 and Teredo encodings aren't decoded.
The URL an OpenAPI plugin ends up calling is influenced by the model (server variables, path parameters), which is what makes this the SSRF surface the module exists for.
To Reproduce
import asyncio
from semantic_kernel.connectors.openapi_plugin.server_url_validator import validate_server_url
asyncio.run(validate_server_url("https://168.63.129.16/machine/")) # returns
asyncio.run(validate_server_url("https://[64:ff9b::169.254.169.254]/latest/meta-data/")) # returns
Full sweep on main @ 7d885dd:
| address | result | category reported |
|---|---|---|
169.254.169.254 (AWS/GCP/Azure/OCI/DO IMDS) |
blocked | link-local |
169.254.170.2 (AWS ECS task creds) |
blocked | link-local |
169.254.170.23 (AWS EKS Pod Identity) |
blocked | link-local |
169.254.42.42 (Scaleway) |
blocked | link-local |
100.100.100.200 (Alibaba) |
blocked | carrier-grade NAT |
192.0.0.192 (Oracle Cloud Classic) |
blocked | reserved |
168.63.129.16 (Azure WireServer) |
allowed | — |
| IPv6 form | result |
|---|---|
::ffff:169.254.169.254 (IPv4-mapped) |
blocked |
::1, fd00:ec2::254 |
blocked |
64:ff9b::169.254.169.254 (NAT64 well-known, RFC 6052) |
allowed |
2002:a9fe:a9fe:: (6to4, RFC 3056) |
allowed |
2001:0:4136:e378:8000:63bf:3fff:fdd2 (Teredo, RFC 4380) |
allowed |
Expected behavior
168.63.129.16 blocked regardless of the private-range classification, and IPv6 forms carrying an embedded IPv4 decoded to that IPv4 before classification.
The Azure one can't be caught by range logic — it needs an explicit metadata denylist, checked before allow_private_network_access returns early, since "let me reach my own network" and "let me reach the host agent's credential endpoint" aren't the same request.
NAT64 needs the 64:ff9b::/96 and 64:ff9b:1::/48 prefixes decoded per RFC 6052 §2.2; 6to4 takes the IPv4 from bits 16–47; Teredo's is the low 32 bits XOR'd with all-ones.
Platform
- OS: Linux
- Python: 3.10.12
- Semantic Kernel:
main@ 7d885dd (python)
Additional context
Reachability varies by deployment — NAT64 needs a gateway on the path, and 6to4/Teredo relays are largely retired, so those three are defence-in-depth rather than universally exploitable. 168.63.129.16 is different: it is directly reachable on any Azure VM with no special network setup, which is where this repo's users are most likely to be running.
The IPv4-mapped unwrapping in try_categorize_non_public_address is already the right shape for the IPv6 side; the other encodings would slot in next to it.
- Ngôn ngữ chính
- C#
- Star
- 28.6k
- Fork
- 4.8k
- Merge trung bình
- 13 giờ 24 phút
- Pull request đã merge (30 ngày)
- 11
Chuẩn bị môi trường
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/semantic-kernel
-
python triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
microsoft/semantic-kernel#14491 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
python triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
microsoft/semantic-kernel#14490 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Python: [Python] structured_outputs_transform reuses ChatHistory across calls (prompt pollution)Đang mởpython triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
microsoft/semantic-kernel#14483 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
.NET python triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
microsoft/semantic-kernel#14482 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Python: [Python] as_agent_framework_tool drops parameter defaults (optionals become required)Đang mởpython triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
microsoft/semantic-kernel#14481 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của microsoft/semantic-kernel
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
NethermindEth/nethermind#14012 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
dependencies Status: Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
json-schema-org/website#2518 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agentic-workflows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
builtbybel/Flyoobe#498 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
builtbybel/CrapFixer#112 ·