DeepSeek Harness-இல், HTTP Host header-ஐ 127.0.0.1 என மாற்றுவதன் மூலம், ஒரு sandboxed தாக்குபவர் தன்னிச்சையான கட்டளைகளை (arbitrary commands) இயக்க முடிந்தது; இது CVSS அளவீட்டில் 9.4 மதிப்பெண்களைப் பெறுகிறது. ஒரு தவறான நம்பிக்கை முடிவு, ஒரு பாதுகாப்பு எல்லையை எவ்வாறு திறந்திருக்கும் ஒரு backdoor ஆக மாற்றும் என்பதை இந்த குறைபாடு காட்டுகிறது.

இந்த பிழை எவ்வாறு நுழைந்தது

இந்த பாதிப்புக்குள்ளான குறியீடு (vulnerable code), கோரிக்கையின் (request) Host header-ஐப் படிக்கும் ஒரு தனிச் செயல்பாட்டில் (function) உள்ளது. அந்த மதிப்பு loopback முகவரியுடன் சமமாக இருந்தால், அந்தக் கோரிக்கை உள்ளூர் இயந்திரத்திலிருந்து (local machine) வருவதாக அது கருதுகிறது.

sandbox-க்குள் குறியீட்டை இயக்கக்கூடிய ஒரு தாக்குபவருக்குச் சிக்கலான payload தேவையில்லை. Host: 127.0.0.1 கொண்ட ஒரு HTTP கோரிக்கையை அனுப்புவதன் மூலம், backend அந்த அழைப்பு host-லிருந்தே வருகிறது என்று நம்பி, அனைத்து பாதுகாப்பு அறிவிப்புகள் (security prompts), rate-limit சோதனைகள் மற்றும் command-validation படிகளைத் தவிர்க்கிறது. இதன் விளைவாக: எந்தவித கூடுதல்த் தொடர்பும் இன்றி தடையற்ற கட்டளைச் செயலாக்கம் (unrestricted command execution) சாத்தியமாகிறது.

Headers-ஐ நம்புவது ஏன் ஆபத்தானது

Headers என்பவை அழைப்பவரால் (caller) வழங்கப்படும் plain-text சரங்கள் (strings) ஆகும். அந்தத் புலத்தின் (field) பெயர் Host, X-Forwarded-For அல்லது ஏதேனும் ஒரு தனிப்பயன் பெயராக இருந்தாலும், கிளையண்ட் (client) விரும்பும் எந்த மதிப்பையும் அதில் அமைக்க முடியும். ஒரு இணைப்பு உண்மையில் எங்கிருந்து வந்தது என்பதற்கான ஒரே நம்பகமான ஆதாரம் transport layer ஆகும் – அதாவது TCP handshake நிறைவடையும் போது இயங்குதளம் (operating system) பதிவு செய்யும் socket-ன் மூல IP முகவரி (source IP address).

ஒரு அறியப்பட்ட, சரியாகக் கட்டமைக்கப்பட்ட proxy அதைச் சேர்த்ததா என்பதை உறுதிப்படுத்தாமல், ஒரு application ஒரு header-ஐ நம்பத் தீர்மானிக்கும்போது, அது தாக்குபவருக்கு முழு அதிகாரத்தையும் (keys to the kingdom) வழங்குகிறது. DeepSeek Harness பிழை இந்தத் தவறான முடிவுக்கு ஒரு சிறந்த உதாரணமாகும்.

நிஜ உலகத் தாக்கம்: shell.online உதாரணம்

இணைய அடிப்படையிலான (web-based) terminal-ஐ வழங்கும் open-source shell.online திட்டம், சமீபத்தில் இதே போன்ற ஒரு சிக்கலை ஆவணப்படுத்தியுள்ளது. இது TRUST_PROXY எனப்படும் ஒரு configuration flag-ஐப் பயன்படுத்துகிறது:

  • TRUST_PROXY = 0 – app, X-Forwarded-For header-ஐப் புறக்கணித்துவிட்டு socket-ன் remote address-ஐ நம்பியிருக்கும். இது rate limits-ஐத் தவிர்க்க அல்லது ஒரு நம்பகமான பயனராகத் தன்னைத் தகவமைத்துக் கொள்ள (masquerade), கிளையண்ட் ஒரு போலி IP முகவரியை உருவாக்குவதைத் தடுக்கிறது.
  • TRUST_PROXY = 1 – app, X-Forwarded-For header-ஐ கிளையண்டின் அடையாளமாகக் கருதி நம்புகிறது. இந்த header-ஐச் சுத்திகரிக்கும் (sanitises) ஒரு உண்மையான proxy-க்கு பின்னால் இந்தச் சேவை இல்லை என்றால், ஒரு தாக்குபவர் ஒவ்வொரு கோரிக்கைக்கும் ஒரு புதிய IP முகவரியை வழங்க முடியும், இது ஒவ்வொரு IP-க்கும் உள்ள throttling-ஐத் திறம்பட மீட்டமைக்கும் (resetting).

DeepSeek பிழை இந்தச் சூழலையே பிரதிபலிக்கிறது: ஒரு proxy-யானது Host-ஐ அமைத்தது போலக் குறியீடு அதை நம்பியது, ஆனால் அந்தச் சேவையை நேரடியாக அணுக முடிந்தது.

டெவலப்பர்கள் இப்போது என்ன செய்ய வேண்டும்

  1. கிளையண்டால் வழங்கப்படும் headers-ஐப் படிக்கும் ஒவ்வொரு இடத்தையும் தணிக்கை (Audit) செய்யுங்கள். எந்தெந்த headers-களை நீங்கள் அதிகாரப்பூர்வமானதாகக் கருதுகிறீர்கள் (உதாரணமாக, Host, X-Forwarded-For, X-Real-IP) என்பதைக் கண்டறிந்து, அவை உங்கள் application-ஐச் சென்றடைவதற்கு முன்பே ஒரு நம்பகமான proxy அவற்றை மாற்றி எழுதுவதை (rewrite) உறுதிப்படுத்தவும்.
  2. முடிந்தவரை பாதுகாப்பு முடிவுகளை socket முகவரியுடன் இணைக்கவும். அங்கீகாரம் (authentication), rate-limiting மற்றும் access-control சோதனைகளுக்கு OS வழங்கும் source IP-யைப் பயன்படுத்தவும்.
  3. சரியாகக் கட்டமைக்கப்பட்ட reverse proxy ஒரு சேவையின் முன்னால் இருக்கும்போது மட்டுமே proxy-trust flags-களை இயக்கவும். நீங்கள் app-ஐ நேரடியாக இயக்கினால், அந்த flags-களை முடக்கி (disabled) வைக்கவும்.
  4. தேவையான deployment topology-யை உங்கள் திட்டத்தின் README அல்லது deployment guide-இல் ஆவணப்படுத்தவும், இதன் மூலம் self-host செய்யும் பயனர்கள் proxy-trust தேவையைப் பற்றித் தெரிந்துகொள்வார்கள்.
  5. static-analysis அல்லது code-review கருவிகளைப் பயன்படுத்தவும். இவை proxy-validation தர்க்கம் (logic) இல்லாமல், பாதுகாப்பு முடிவுகளுக்காக headers-களை நேரடியாகப் பயன்படுத்துவதைக் கண்டறிந்து எச்சரிக்கும்.

அடுத்து கவனிக்க வேண்டியவை

இந்தச் சம்பவத்திற்குப் பிறகு, self-hosted web சேவைகளை வழங்கும் சமூகங்கள் தங்களின் சொந்த proxy-trust அமைப்புகளை மீண்டும் ஆய்வு செய்ய வாய்ப்புள்ளது.

இதன் முக்கிய பாடம் மிகத் தெளிவானது: இணையத்தில் எவர் வேண்டுமானாலும் எழுதக்கூடிய ஒரு உரைத் துண்டு (piece of text), உங்கள் அமைப்பின் பாதுகாப்பு நிலையைத் தீர்மானிக்க அனுமதிக்காதீர்கள். request layer-ஐ நம்பாதீர்கள், network layer-ஐ நம்புங்கள்.