Mini Shai-Hulud tấn công trở lại: 314 gói npm bị xâm phạm

 (safedep.io)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Tài khoản npm atool đã bị xâm phạm vào ngày 19 tháng 5 năm 2026, khiến 637 phiên bản độc hại được tự động phát hành trên 317 gói trong khoảng 22 phút
  • Payload là một script Bun bị làm rối dung lượng 498KB, sử dụng cùng cấu trúc trình quét và biểu thức chính quy như Mini Shai-Hulud từng được dùng trong vụ xâm phạm SAP
  • Mục tiêu đánh cắp mở rộng tới thông tin xác thực AWS, token Kubernetes, Vault, GitHub PAT, token npm, khóa SSH và cả các bí mật cục bộ
  • Trong môi trường CI, nó đổi GitHub Actions OIDC lấy token publish npm và lạm dụng chữ ký Sigstore cùng việc chèn workflow độc hại
  • Ứng phó cần bao gồm kiểm tra xem có cài phiên bản bị xâm phạm hay không, thay toàn bộ thông tin xác thực từng có thể bị truy cập, đồng thời áp dụng lockfile·ghim phụ thuộc và kiểm tra trước khi cài đặt

Tổng quan cuộc tấn công

  • Tài khoản npm atool (i@hust.cc) đã bị xâm phạm vào ngày 19 tháng 5 năm 2026 và trong khoảng 22 phút đã phát hành 637 phiên bản độc hại trên 317 gói
  • Tài khoản này đang duy trì 547 gói, và kẻ tấn công đã thực hiện tăng phiên bản hai lần trên hơn 314 gói trong số đó
  • Các gói bị ảnh hưởng bao gồm size-sensor (4,2 triệu lượt tải mỗi tháng), echarts-for-react (3,8 triệu), @antv/scale (2,2 triệu), timeago.js (1,15 triệu) và nhiều gói trong scope @antv
  • Payload là một script Bun bị làm rối dung lượng 498KB, sử dụng cùng cấu trúc trình quét, regex thông tin xác thực và mẫu làm rối như Mini Shai-Hulud toolkit từng được dùng trong vụ xâm phạm SAP ba tuần trước
  • Dữ liệu đánh cắp được либо commit vào kho GitHub công khai dưới dạng đối tượng Git, hoặc gửi qua HTTPS POST tới t.m-kosche[.]com sau khi được mã hóa bằng RSA+AES

Cách phát hành và rủi ro semver

  • Đợt đầu tiên diễn ra từ 01:39 đến 01:56 UTC ngày 19 tháng 5 năm 2026, phát hành khoảng 317 phiên bản; đợt thứ hai từ 02:05 đến 02:06 UTC thực hiện khoảng 314 lần tăng phiên bản trên cùng các gói đó
  • Phần lớn trong 309 gói đã nhận chính xác 2 phiên bản độc hại, mỗi đợt một phiên bản
  • Bốn gói size-sensor, echarts-for-react, jest-canvas-mock, jest-date-mock nhận 3 phiên bản, cho thấy chúng đã được dùng trong thử nghiệm ban đầu
  • Kẻ tấn công hầu như không di chuyển dist-tag latest trên đa số gói, nhưng cách npm diễn giải semver vẫn chọn phiên bản cao nhất phù hợp với dải chỉ định, bất kể latest
  • Ví dụ, dù latest của echarts-for-react vẫn ở 3.0.6, một dự án khai báo "echarts-for-react": "^3.0.6" có thể bị phân giải sang phiên bản độc hại 3.2.7 trong lần cài sạch tiếp theo

Đường thực thi và payload

  • Tất cả các phiên bản bị chỉnh sửa đều thêm tăng phiên bản và "preinstall": "bun run index.js" vào package.json
  • Trong 637 phiên bản độc hại, 630 phiên bản thêm @antv/setup: github:antvis/G2#<commit-sha> vào optionalDependencies để kéo về bản sao payload thứ hai
  • Hook preinstall chạy trước khi cài phụ thuộc và yêu cầu runtime Bun
  • Ngay cả khi preinstall bị chặn hoặc bị bỏ qua, script prepare trong commit giả mạo GitHub vẫn còn là đường thực thi thứ hai
  • index.js là một bundle Bun bị làm rối một dòng dung lượng 498KB, có cùng yêu cầu Bun, kỹ thuật làm rối bằng biến hex, cấu trúc trình quét với ngưỡng flush 100KB và bộ regex thông tin xác thực như Mini Shai-Hulud payload dùng trong vụ xâm phạm SAP
  • Việc nhận diện môi trường CI kiểm tra biến môi trường của hơn 20 nền tảng, bao gồm GitHub Actions, Jenkins, GitLab CI, CircleCI, Travis, Buildkite, Drone, TeamCity, AppVeyor, Bitbucket Pipelines, CodeBuild, Azure DevOps, Netlify và Vercel

Mục tiêu thu thập thông tin xác thực

  • Payload đọc hơn 80 biến môi trường có tên được mã hóa và quét nội dung tệp bằng regex
  • Các mục tiêu chính gồm token GitHub, token npm, JWT GitHub Actions, khóa AWS, khóa Azure, chuỗi kết nối DB, khóa Stripe, khóa SSH, xác thực Docker, token Vault, token Kubernetes và thông tin xác thực nhúng trong URL
  • Trình quét tệp đọc các vị trí thông tin xác thực tiêu chuẩn trong thư mục home như .ssh, .aws/credentials, .npmrc, .docker/config.json, .kube/config
  • Nó duyệt toàn bộ thứ tự phân giải thông tin xác thực AWS, lấy thông tin xác thực IAM role từ EC2 IMDSv2 và endpoint thông tin xác thực container ECS, đồng thời thử gọi AWS STS GetCallerIdentity và truy cập Secrets Manager
  • Với Vault, nó kiểm tra tệp token cùng VAULT_ADDR, VAULT_TOKEN, VAULT_ROLE và các biến liên quan, rồi nếu có thông tin xác thực hợp lệ sẽ thử liệt kê secret và xác thực AWS·Kubernetes
  • Với Kubernetes, nó kiểm tra service account token và KUBECONFIG; nếu có Docker socket, nó sẽ thử liệt kê container của máy chủ và thoát khỏi container

C2 và rò rỉ dữ liệu

  • GitHub API được dùng như C2: GET /user để xác minh token GitHub đã đánh cắp và GET /user/orgs để liệt kê tổ chức
  • Các token có quyền repo hoặc public_repo sẽ được dùng để tạo kho dùng cho mục đích rò rỉ của kẻ tấn công
  • Phần mô tả kho được lưu bằng chuỗi đảo ngược niagA oG eW ereH :duluH-iahS, khi đảo lại thành “Shai-Hulud: Here We Go Again”
  • Tên kho kết hợp hai từ theo chủ đề Dune với một con số, như harkonnen-melange-742, fremen-sandworm-315, gesserit-navigator-508
  • Dữ liệu bị đánh cắp được lưu qua Git Data API theo thứ tự blob, tree, commit rồi cập nhật ref
  • Một bộ gửi HTTPS riêng được dựng để trông giống endpoint ingest trace OpenTelemetry OTLP tại hxxps://t.m-kosche[.]com/api/public/otel/v1/traces
  • Payload HTTPS mã hóa JSON gzip bằng AES-256-GCM, rồi bọc khóa AES bằng RSA-OAEP với khóa công khai được hardcode

Lạm dụng CI/CD và chuỗi tin cậy

  • Từ các kho GitHub mà token đánh cắp truy cập được, nó thu thập lịch sử chạy workflow, artifact, tên secret, danh sách branch và cấu hình Claude Code
  • Dù không thể truy cập giá trị secret qua GitHub API, tên secret vẫn cho biết những loại thông tin xác thực nào đang tồn tại
  • Workflow độc hại được chèn vào .github/workflows/codeql.yml, có tên Run Copilot và kích hoạt khi push
  • Workflow đưa toàn bộ repository secrets vào biến môi trường dưới dạng JSON bằng VARIABLE_STORE: ${{ toJSON(secrets) }}, lưu vào format-results.txt rồi tải lên như artifact
  • Sau khi hoàn tất, nó tải xuống file zip artifact, xóa workflow run và reset branch ref để giảm dấu vết chèn mã độc
  • Trong CI có GitHub Actions OIDC, nó thử đổi lấy token publish npm qua endpoint https://registry.npmjs.org/-/npm/…;
  • Payload có triển khai ký Sigstore, bao gồm các định dạng Fulcio, Rekor và SLSA provenance, cho phép tạo artifact được ký bằng danh tính CI đã bị xâm phạm

Môi trường phát triển và lây nhiễm AI coding agent

  • Payload nhắm vào môi trường Claude Code, Codex và VS Code thông qua tiêm từ xa qua GitHub API và lây nhiễm cục bộ bằng cách ghi vào hệ thống tệp
  • Nó commit các tệp .vscode/tasks.json, .claude/index.js, .claude/settings.json, .claude/setup.mjs, .vscode/setup.mjs vào các kho lưu trữ mà token đánh cắp có thể truy cập
  • .claude/settings.json đăng ký hook SessionStart để chạy node .claude/setup.mjs mỗi khi một phiên Claude Code bắt đầu
  • .vscode/tasks.json kích hoạt thực thi khi thư mục dự án được mở bằng "runOn": "folderOpen"
  • setup.mjs tải Bun v1.3.14 từ bản phát hành chính thức trên GitHub, giải nén binary rồi thực thi payload
  • Đường lây nhiễm cục bộ sao chép payload vào ~/.claude/package/index.js và ~/.codex/package/index.js, rồi quét các tệp cấu hình dự án hiện có để tiêm hook
  • Trên máy Mac Apple Silicon, đường lây nhiễm cục bộ này bị bỏ qua; trên Linux, Mac Intel và Windows thì được thực thi

Cơ chế bám trụ và GitHub dead-drop C2

  • Một daemon chạy dai dẳng ngụy trang thành kitty-monitor được cài dưới dạng dịch vụ người dùng systemd trên Linux, và dưới dạng ~/Library/LaunchAgents/com.user.kitty-monitor.plist trên macOS
  • Trình cài đặt dùng systemctl --user enable --now và loginctl enable-linger để duy trì hoạt động ngay cả sau khi đăng xuất
  • Daemon cat.py polling GitHub Search API mỗi giờ một lần và tìm các commit có chứa từ khóa firedalazer
  • Định dạng commit message là firedalazer <base64_url>.<base64_signature>, sau đó xác minh chữ ký RSA-PSS bằng khóa công khai RSA 4096-bit được hardcode rồi thực thi mã Python từ URL
  • Một daemon riêng gh-token-monitor polling các GitHub token bị đánh cắp mỗi 60 giây, với TTL là 24 giờ
  • Trình quét bộ nhớ tiến trình dump các vùng bộ nhớ có thể đọc được của tiến trình worker GitHub Actions runner bằng /proc/pid/maps+mem trên Linux và ReadProcessMemory trên Windows

Commit giả mạo antvis/G2

  • Trong 637 phiên bản độc hại, 630 phiên bản chứa mục optionalDependencies trỏ tới một commit cụ thể trong kho antvis/G2 
    {
  "optionalDependencies": {
    "@antv/setup": "github:antvis/G2#1916faa365f2788b6e193514872d51a242876569"
  }
}
  • Khi npm phân giải phụ thuộc github:, nó sẽ lấy commit đó, tìm package.json, rồi chạy các lifecycle script
  • Commit đó chứa package.json khai báo @antv/setup và có script prepare, cùng với tệp index.js 499KB là cùng payload Shai-Hulud nhưng đã được làm rối lại
  • Phần && exit 1 trong script prepare khiến optional dependency thất bại, nhưng npm không coi lỗi optional dependency là nghiêm trọng nên quá trình cài đặt vẫn tiếp tục
  • Git API cho thấy 3 commit SHA khác nhau đã được push vào antvis/G2, và tất cả đều không gắn với bất kỳ branch nào
  • Cả ba commit chia sẻ cùng metadata: author huiyu.zjt <Alexzjt@users.noreply.github.com>, commit message New Package, không có parent, và không có chữ ký GPG
  • Kẻ tấn công có thể để lại các commit mồ côi chứa payload vẫn có thể fetch bằng SHA trong namespace của kho cha bằng cách tạo orphan commit payload trong fork rồi xóa fork đó, ngay cả khi không có quyền ghi vào antvis/G2
  • Cách này cùng loại với vấn đề commit giả mạo trong GitHub Actions mà Chainguard đã tài liệu hóa, nhưng ở đây được áp dụng cho cơ chế phân giải phụ thuộc npm github:

Chỉ dấu xâm phạm

  • Cần kiểm tra các gói do atool(i@hust.cc) phát hành trong khoảng 01:44~02:06 UTC ngày 19 tháng 5 năm 2026
  • Script preinstall là bun run index.js
  • SHA256 của payload là a68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1c
  • Các commit giả mạo antvis/G2 như sau
    • 1916faa365f2788b6e193514872d51a242876569 — 626 phiên bản
    • 7cb42f57561c321ecb09b4552802ae0ac55b3a7a — 2 phiên bản
    • dc3d62a2181beb9f326952a2d212900c94f2e13d — 1 phiên bản, đã bị garbage collected
  • IoC mạng bao gồm hxxps://t.m-kosche[.]com/api/public/otel/v1/traces, metadata EC2 169.254.169.254, và các yêu cầu metadata container ECS tới 169.254.170.2
  • IoC kho mã bao gồm branch chore/add-codeql-static-analysis, workflow Run Copilot, và .github/workflows/codeql.yml dump toJSON(secrets) vào format-results.txt
  • IoC môi trường phát triển bao gồm hook SessionStart trong .claude/settings.json, "runOn": "folderOpen" trong .vscode/tasks.json, .claude/setup.mjs, và .vscode/setup.mjs
  • IoC cơ chế bám trụ bao gồm kitty-monitor.service, com.user.kitty-monitor.plist, ~/.local/bin/gh-token-monitor.sh, ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state

Các gói tiêu biểu cần kiểm tra

  • Bảng compromised-packages.csv có 2 cột Package và Compromised Versions, và theo bảng có 317 gói được liệt kê
  • Cần kiểm tra trong lockfile xem có các gói đó và các phiên bản độc hại được phát hành vào ngày 2026-05-19 hay không
  • Các gói @antv tiêu biểu và phiên bản độc hại
    • @antv/g2: 5.5.8, 5.6.8
    • @antv/g6: 5.2.1, 5.3.1
    • @antv/g: 6.4.1, 6.5.1
    • @antv/l7: 2.26.10, 2.27.10
    • @antv/x6: 3.2.7, 3.3.7
    • @antv/s2: 2.8.1, 2.9.1
    • @antv/f2: 5.15.0, 5.16.0
  • Các gói npm phổ biến và phiên bản độc hại
    • echarts-for-react: 3.0.7, 3.1.7, 3.2.7
    • size-sensor: 1.0.4, 1.1.4, 1.2.4
    • jest-canvas-mock: 2.5.3, 2.6.3, 2.7.3
    • jest-date-mock: 1.0.11, 1.1.11, 1.2.11
    • timeago.js: 4.1.2, 4.2.2
    • timeago-react: 3.1.7, 3.2.7
    • @lint-md/cli: 2.1.0, 2.2.0
    • @lint-md/core: 2.1.0, 2.2.0
    • @lint-md/parser: 0.1.14, 0.2.14

Ứng phó và phòng vệ

  • Nếu đã cài đặt phiên bản bị xâm phạm, cần thay thế các token npm, GitHub PAT, khóa AWS, khóa SSH, thông tin xác thực đám mây, mật khẩu cơ sở dữ liệu, token Vault, token service account Kubernetes và các bí mật trong trình quản lý mật khẩu cục bộ mà môi trường build có thể truy cập
  • Cần chặn t.m-kosche[.]com ở cấp độ mạng và DNS
  • Cần kiểm tra xem có kho lưu trữ công khai trái phép nào được tạo dưới tài khoản GitHub có token mà môi trường build có thể truy cập hay không
  • Cần rà soát việc publish gói trái phép và log trao đổi token npm OIDC trong pipeline CI
  • Cần kiểm tra log minh bạch Sigstore để xác định có artifact đã ký nào được tạo bằng CI identity bị xâm phạm hay không
  • Cần kiểm tra các hook .claude/settings.json, tác vụ tự động chạy .vscode/tasks.json, .claude/setup.mjs, .vscode/setup.mjs trong các dự án Node.js cục bộ
  • Cần gỡ bỏ dịch vụ người dùng systemd kitty-monitor và LaunchAgent com.user.kitty-monitor, đồng thời kiểm tra sự hiện diện của ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state, ~/.local/bin/gh-token-monitor.sh
  • Cần pin dependency hoặc sử dụng lockfile để việc diễn giải phạm vi semver không dẫn đến phiên bản độc hại
  • Cần kiểm tra việc lộ Docker socket và quyền truy cập EC2 metadata trong pipeline CI/CD, đồng thời cân nhắc áp dụng giới hạn hop limit của IMDSv2
  • Package Manager Guard (pmg) là proxy cài đặt mã nguồn mở đối chiếu gói với threat intelligence trước khi thực thi preinstall
  • dependency cooldown có thể từ chối các phiên bản được phát hành trong một cửa sổ thời gian có thể cấu hình, giúp giảm các làn sóng phát hành dồn dập khi phạm vi semver được diễn giải thành bản phát hành độc hại mới
  • vet có thể phát hiện các bản cập nhật gói bất thường như hook preinstall ngoài dự kiến, kích thước tăng đột biến hoặc thay đổi maintainer trước khi chúng đi tới pipeline CI/CD
  • Phạm vi ảnh hưởng gồm 547 gói dưới một tài khoản duy nhất và hơn 314 gói bị vũ khí hóa trong một phiên cho thấy điểm yếu mang tính cấu trúc trong mô hình tin cậy của npm

Tài liệu tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Đến lúc phải vô hiệu hóa script vòng đời NPM theo mặc định
    Về cơ bản, đây là việc tích hợp sẵn khả năng thực thi mã tùy ý dưới danh nghĩa tính năng tiện lợi, và nó còn áp dụng cả cho phụ thuộc bắc cầu. Mọi kiểu tấn công dạng sâu NPM lan rộng đều đã phát tán thông qua thiết lập mặc định này. Không nên để việc bật một lần cho một lệnh cụ thể lại cho phép toàn bộ phụ thuộc bắc cầu chạy script vòng đời; thay vào đó phải yêu cầu đánh dấu tường minh cho từng phụ thuộc thật sự cần thiết
    Đại đa số gói NPM không phụ thuộc vào các script này, nên nếu chưa làm thì tốt nhất hãy tắt nó trên toàn cục

    • Có RFC cho việc này: https://github.com/npm/rfcs/pull/868
    • Hoặc cứ dùng pnpm là được
    • Đúng vậy. Hoặc ít nhất nó phải chạy trong sandbox. Nếu là script hậu cài đặt chạy lệnh tùy ý trong đúng ngữ cảnh của chính gói được cài thì còn chấp nhận được, nhưng kết hợp giữa script tùy ý và quyền người dùng là công thức cho thảm họa
      Dù vậy, bản thân gói vẫn có thể chạy đủ thứ rác rưởi chúng muốn ngay khi được import lần đầu trong chương trình

  • Câu “không có cách ngăn chặn” chỉ xuất hiện ở trình quản lý gói duy nhất mà chuyện này xảy ra định kỳ

    • Ngoài chuyện NPM là trình quản lý gói phổ biến nhất, còn có yếu tố nào khiến nó đặc biệt dễ tổn thương trước các kiểu tấn công này không?

  • Từ một thời điểm nào đó, có lẽ tắt Dependabot và ghim mọi gói NPM xuống tận phiên bản minor/patch lại tốt hơn là cứ tiếp tục cập nhật
    Đặc biệt với các gói frontend, có vẻ các bản vá bảo mật thật sự có ý nghĩa giờ còn hiếm hơn cả tấn công chuỗi cung ứng
    Thật đáng buồn, nhưng có lý do gì để không chuyển frontend sang BOM tĩnh và tin rằng NPM ít nhất sẽ giữ đúng ràng buộc “không thể tái phát hành phiên bản cũ” không?

    • Rồi đội compliance sẽ khó chịu vì còn sót lại một CVE CVSS 3.1 chưa vá dù đã có bản sửa
    • Chỉ cần áp dụng thời gian ủ bắt buộc. Ví dụ, không cho bất kỳ pull request nào đưa vào phiên bản mới hơn 30 ngày
      Có thể đặt ngoại lệ cho các phiên bản sửa CVE đã biết
    • Đúng thế. Đó cũng là một trong những lý do các hệ sinh thái khác ít thấy tấn công chuỗi cung ứng hơn
    • Chẳng phải NPM tạo lockfile đầy đủ bao gồm cả hash và phụ thuộc bắc cầu đã được cố định sao?

  • Tình hình ngày càng điên rồ. Cá nhân tôi thì đã gỡ node, python và mọi trình quản lý gói khỏi máy của mình, thay vào đó chỉ dùng chúng trong devcontainer hoặc VM
    Kể cả khi cộng đồng lập trình viên tạo ra được các lớp bảo mật cực mạnh, tôi vẫn lo rằng trong khoảng 1 năm nữa, năng lực social engineering của mô hình sẽ đủ giỏi để đây vẫn là một cuộc chơi thua cuộc

    • Nếu mô hình thật sự rất giỏi social engineering, tôi không rõ vì sao về nguyên tắc điều đó lại tạo ra tác động lớn đến thế. Lợi nhuận giảm dần là có thật, và nút thắt là mục tiêu vẫn vận hành ở tốc độ con người
      Ví dụ, vụ hack XZ đòi hỏi nỗ lực khổng lồ và không thể tăng tốc vì nó dựa vào việc bào mòn người bảo trì hiện tại theo thời gian. Bạn có thể tạo và gửi thông điệp độc hại cần thiết trong vài giây, nhưng tốc độ đọc của con người không tăng lên, và nếu chúng đến cùng lúc thì thậm chí còn dễ gây nghi ngờ hơn
      Khả năng thuyết phục của đầu vào cũng có giới hạn. Có thể bạn chọn một thông điệp độc hại bất kỳ gửi đến maintainer của XZ rồi làm nó hiểm hơn, chính xác hơn, phản ánh đúng điểm yếu cá nhân và nỗi sợ của người đó hơn, nhưng xét tổng thể liệu nó có hiệu quả hơn không? Có lẽ là không, hoặc cùng lắm chỉ nhỉnh hơn một chút
    • Container giải quyết vấn đề này kiểu gì? Nếu nó có kết nối Internet, mà thực tế là vậy, và nếu container có thể đọc credential, thì chẳng phải vẫn là cùng một vấn đề sao?
    • Không có node thì bạn điều khiển tài nguyên cloud kiểu gì? Cloudflare cần wrangler, và AWS cũng có khá nhiều CLI viết bằng node

  • Giờ Zed đã lên 1.0 nên tôi muốn chuyển hẳn sang, nhưng theo tôi biết thì mô hình bảo mật của nó là tất cả hoặc không gì cả. Hoặc bạn cho phép nó tùy ý tải về và cài các gói NPM mà bạn không hề biết, hoặc phải tắt toàn bộ tính năng LSP
    Vậy mà tin kiểu này cứ liên tục xuất hiện

  • Liệu npm có thể vận hành một chương trình tự động trì hoãn việc upload gói khoảng 10 phút, và trong khoảng đó phân phối nó tới một hệ sinh thái công ty kiểm toán mã bên thứ ba để quét tự động không
    Họ thậm chí có thể làm bảng xếp hạng công khai xem đơn vị kiểm toán nào bắt lỗi nhanh và ổn định nhất, hoặc thưởng tiền

  • Danh sách này chưa đầy đủ. Ít nhất còn một gói khác nữa, extension VS Code nx-console, cũng đã bị nhiễm con sâu này hôm qua và có 2,2 triệu lượt tải
    Nếu có ai có đủ thẩm quyền và kết nối đang đọc được điều này, sẽ đáng để lần theo chuỗi phụ thuộc đó để xem còn gì nữa không. Tham khảo ở đây:
    https://github.com/nrwl/nx-console/security/advisories/GHSA-...
    PS: Tôi đã đăng lên HN để báo cho mọi người ngay sau khi nó bị nhiễm, nhưng tiếc là hầu như không được upvote

  • Xét trên toàn bộ hệ sinh thái, TC39 nên xem xét bổ sung thư viện chuẩn tốt hơn cho chính JS. Như vậy có thể giảm số lượng các gói một dòng
    Đồng ý. Hồi trước khi làm việc với Deno, phần tôi thích nhất là thư viện chuẩn[0] và môi trường phát triển nhìn chung khá hoàn chỉnh. Việc runtime tích hợp sẵn test runner và thư viện assertion là điều quá hiển nhiên
    0 - https://docs.deno.com/runtime/reference/std/

    • Công bằng mà nói thì Node cũng đã cung cấp sẵn các module node:test [0] và node:assert/strict [1] từ vài bản LTS trước. node --test có thể dễ dàng thay thế Mocha, còn node:assert/strict cũng ổn, dù đôi khi chai tiện hơn nhờ trải nghiệm kiểu expect. @std của Deno có thư viện assertion theo phong cách expect
      Vấn đề là hệ sinh thái Node có quá nhiều test runner, và khá nhiều trong số đó không dễ thay thế như Mocha. Vì vậy quá trình chuyển sang test harness và thư viện assertion tích hợp sẵn đương nhiên sẽ rất chậm và đau đớn. Mọi người thích bản chất phức tạp quá mức của Jest và Vitest vì nhiều lý do khác nhau. Các tập đoàn lớn từng nghĩ Karma là ý tưởng hay. Đến giờ tôi vẫn không hiểu vì sao không nhiều lập trình viên hơn ghét kiểu “à, bạn thích V8 cho unit test đúng không? Thế thì chúng tôi sẽ khởi chạy thêm một bản sao V8 nữa bên trong môi trường V8 hiện có của bạn”
      [0] https://nodejs.org/api/test.html
      [1] https://nodejs.org/api/assert.html#strict-assertion-mode
    • Tôi không chắc những gói được nêu ở đây thì cái nào sẽ thuộc về một “thư viện chuẩn tốt hơn”
      Thư viện chuẩn của ngôn ngữ nào lại có bộ chuyển đổi kiểu “3 giờ trước”? Đó là việc timeago.js làm
      slice.js thì chỉ cung cấp đánh chỉ số âm kiểu Python. TC39 thực ra đã khiến array.at() và array.slice() xử lý được số âm rồi
    • Thư viện chuẩn của Node.js dạo này cũng đang tiếp tục phình ra, và cũng đáng nói là nó bao gồm cả hỗ trợ assertion và test như đã nhắc ở trên
      https://nodejs.org/api/

  • Nghe nói payload sẽ kiểm tra Docker socket, và nếu có thì nó thử thoát container bằng ba phương pháp tuần tự
    Vì vậy kể cả bạn chạy trong devcontainer hay VM, loại sâu này cũng đã đang cố chui ra ngoài
    Cần bảo đảm bạn đang dùng engine VM chạy rootless. Ví dụ như podman thay cho Docker

    • Dù một số người, kể cả trong ngành bảo mật, nói khác đi, Docker không phải ranh giới bảo mật mạnh và không nên bị đối xử như vậy. Nó dùng chung hệ thống đang chạy và kernel hiện có
      Điều này làm tôi nhớ thời người ta phát tài khoản Linux ít quyền rồi tin rằng kernel sẽ ngăn leo thang đặc quyền. Docker về cơ bản đúng là chuyện đó, chỉ thêm nhiều thủ tục hơn. Nhất là thời nay cứ như thể 5 phút lại xuất hiện một lỗ hổng leo thang đặc quyền cục bộ mới trong kernel
      Podman có phần khá hơn ở chỗ không trao root cho kẻ tấn công, nhưng ngay từ đầu tại sao lại phải đưa cho chúng tài khoản? Cứ dùng VM đúng nghĩa là được
    • Chỉ cần đừng mount Docker socket vào trong container
    • Sẽ thật tuyệt nếu có thứ gì gần với jails hay zones hơn. Tốt hơn nữa là đặt container bên trong jail hoặc zone
      Linux có cơ chế sandbox toàn diện kiểu BSD không?
    • Sao không dùng máy ảo đúng nghĩa?
    • Chẳng phải đa số mọi người chạy Docker ở chế độ rootless, ít nhất là trên Linux sao? podman còn làm thêm gì khác nữa?

  • Tôi muốn xuống khỏi Mr Bones' Wild Ride lắm rồi, nhưng lại sợ chuyện này sẽ còn tiếp diễn. Theo những gì tôi xem qua, khá nhiều chiến lược phát hiện thương mại được thiết kế ở cấp kho/lần tải/gói/thiết bị/lập trình viên khi gói được nạp hoặc sử dụng
    Nó trông khá giống cách xử lý email spam hay malware nói chung. Vì vậy gần như luôn sẽ tồn tại các mục tiêu đủ giá trị để tác nhân xấu tiếp tục thử. Nhưng khác với email, trình quản lý gói là một cơ quan quyền lực tập trung, và những vấn đề ngoài băng tần rất dễ mặc định bị đẩy sang trách nhiệm của lập trình viên
    Từ góc nhìn của người ngoài, có lẽ cần rời bỏ văn hóa phát hành nhanh và quản lý phiên bản lỏng lẻo để tập trung vào các phiên bản ổn định, được kiểm tra sâu trong registry. Tôi có thể sai vì hiệu ứng số lượng và quy mô, nhưng việc những ngôn ngữ biến động nhanh dường như bị ảnh hưởng thường xuyên hơn vẫn là điều đáng suy nghĩ
    Sẽ rất tuyệt nếu có một bài viết bao quát toàn diện bức tranh hiện tại

    • Tôi đã tra xem Mr Bones' Wild Ride có phải là tham chiếu đến bộ phim Nothing But Trouble năm 1991 không, nhưng hóa ra tôi nhớ nhầm
      Tên tàu lượn trong phim đó là Mr Bonestripper: https://www.youtube.com/watch?v=NEZEgd8GjJc
      Thay vào đó, nó xuất phát từ Roller Coaster Tycoon 2: https://knowyourmeme.com/memes/mr-bones-wild-ride
      Nếu so với spam, chúng ta về cơ bản đã chấp nhận việc hút địa chỉ email từ gần như mọi môi trường mạng máy tính thương mại và xã hội, khiến người ta phải nhận spam, rồi khoác cho nó một vẻ ngoài hợp pháp. Khả năng lớn là điều tương tự sẽ xảy ra trong lĩnh vực này. Có lẽ đó sẽ là kiểu kết hợp giữa phần mềm dạng agent giám sát giấy phép Oracle và quản lý phụ thuộc tự động, tức là “giải quyết” malware chuỗi cung ứng bằng cách đưa loại malware khác vào danh sách cho phép