PVS-Studio के साथ rdesktop और xrdp की जाँच करना

आरडीपी प्रोटोकॉल के साथ काम करने वाले ओपन-सोर्स सॉफ़्टवेयर की जांच के परिणामों के बारे में लेखों की हमारी श्रृंखला में यह दूसरी पोस्ट है। आज हम rdesktop क्लाइंट और xrdp सर्वर पर एक नज़र डालने जा रहे हैं।

विश्लेषण पीवीएस-स्टूडियो द्वारा किया गया था। यह C, C ++, C #, और Java में लिखे गए कोड के लिए एक स्थिर विश्लेषक है, और यह विंडोज, लिनक्स और मैकओएस पर चलता है।

मैं केवल उन बगों पर चर्चा करूंगा जो मेरे लिए सबसे दिलचस्प लग रहे थे। दूसरी ओर, चूंकि परियोजनाएं बहुत छोटी हैं, वैसे भी उनमें कई कीड़े नहीं हैं :)।

नोट। FreeRDP की जाँच के बारे में पिछला लेख यहाँ उपलब्ध है ।

rdesktop

rdesktop UNIX- आधारित सिस्टम के लिए एक निशुल्क RDP क्लाइंट है। अगर यह सिगविन के तहत बनाया गया है तो यह विंडोज पर भी चल सकता है। Rdesktop को GPLv3 के तहत रिलीज़ किया गया है।

यह एक बहुत ही लोकप्रिय क्लाइंट है। इसका उपयोग ReactOS पर एक डिफ़ॉल्ट क्लाइंट के रूप में किया जाता है, और आप इसके साथ जाने के लिए तृतीय-पक्ष ग्राफ़िकल फ्रंट-एंड भी पा सकते हैं। यह परियोजना बहुत पुरानी है, हालांकि: यह 4 अप्रैल, 2001 को पहली बार जारी की गई थी, और इस लेखन के रूप में, 17 साल पुरानी है।

जैसा कि मैंने पहले ही कहा था, परियोजना बहुत छोटी है - लगभग 30 KLOC, जो कि इसकी उम्र को देखते हुए थोड़ा अजीब है। इसकी तुलना 320R KLOC के साथ FreeRDP से करें। यहाँ क्लॉक का आउटपुट है:

अगम्य कोड

V779 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। rdesktop.c 1502

int main(int argc, char *argv[]) { .... return handle_disconnect_reason(deactivated, ext_disc_reason); if (g_redirect_username) xfree(g_redirect_username); xfree(g_username); } 

पहली त्रुटि मुख्य फ़ंक्शन में तुरंत मिलती है: रिटर्न स्टेटमेंट के बाद का कोड पहले आवंटित की गई मेमोरी को मुक्त करने के लिए था। लेकिन यह दोष खतरनाक नहीं है क्योंकि कार्यक्रम समाप्त होने के बाद पहले से आवंटित सभी मेमोरी को ऑपरेटिंग सिस्टम द्वारा मुक्त कर दिया जाएगा।

कोई त्रुटि से निपटने

V557 ऐरे अंडररून संभव है। 'N' इंडेक्स का मान -1 तक पहुंच सकता है। rdesktop.c 1872

 RD_BOOL subprocess(char *const argv[], str_handle_lines_t linehandler, void *data) { int n = 1; char output[256]; .... while (n > 0) { n = read(fd[0], output, 255); output[n] = '\0'; // <= str_handle_lines(output, &rest, linehandler, data); } .... } 

EOF तक पहुंचने तक फ़ाइल सामग्री बफर में पढ़ी जाती है। इसी समय, इस कोड में एक त्रुटि हैंडलिंग तंत्र का अभाव है, और यदि कुछ गलत होता है, तो रीड -1 वापस आ जाएगा और निष्पादन आउटपुट सरणी की सीमा से आगे पढ़ना शुरू कर देगा।

ईओएफ का उपयोग चार में

V739 ईओएफ की तुलना 'चार' प्रकार के मूल्य से नहीं की जानी चाहिए। '(C = fgetc (fp))' 'int' प्रकार का होना चाहिए। ctrl.c 500

 int ctrl_send_command(const char *cmd, const char *arg) { char result[CTRL_RESULT_SIZE], c, *escaped; .... while ((c = fgetc(fp)) != EOF && index < CTRL_RESULT_SIZE && c != '\n') { result[index] = c; index++; } .... } 

यह कोड गलत EOF हैंडलिंग को लागू करता है: यदि fgetc एक वर्ण देता है जिसका कोड 0xFF है, तो इसे फ़ाइल के अंत ( EOF ) के रूप में समझा जाएगा।

EOF एक स्थिरांक है जिसे आमतौर पर -1 के रूप में परिभाषित किया जाता है। उदाहरण के लिए, CP1251 एन्कोडिंग में, रूसी वर्णमाला के अंतिम अक्षर को 0xFF के रूप में एन्कोड किया गया है, जो टाइप चार में नंबर -1 से मेल खाती है। इसका अर्थ है कि EOF (-1) की तरह ही 0xFF वर्ण, फ़ाइल के अंत के रूप में व्याख्या किया जाएगा। उस तरह की त्रुटियों से बचने के लिए, fgetc फ़ंक्शन द्वारा लौटाए गए परिणाम को टाइप इंट के चर में संग्रहीत किया जाना चाहिए।

लेखन त्रुटियां

स्निपेट 1

V547 अभिव्यक्ति 'राइट_टाइम' हमेशा झूठी होती है। disk.c 805

 RD_NTSTATUS disk_set_information(....) { time_t write_time, change_time, access_time, mod_time; .... if (write_time || change_time) mod_time = MIN(write_time, change_time); else mod_time = write_time ? write_time : change_time; // <= .... } 

इस कोड के लेखक ने गलती से उपयोग किया होगा || ऑपरेटर और स्थिति में && के बजाय। आइए देखें कि वैरिएबल राइट_टाइम और चेंज_टाइम के क्या मान हो सकते हैं:

• दोनों चर हैं 0. इस मामले में, निष्पादन दूसरी शाखा पर जाता है: mod_time चर का मूल्यांकन हमेशा 0 से किया जाएगा, कोई फर्क नहीं पड़ता कि अगली स्थिति क्या है।
• चरों में से एक में 0. है। इस मामले में, mod_time को 0 दिया जाएगा (यह देखते हुए कि दूसरे चर का गैर-ऋणात्मक मान है) क्योंकि MIN कम से कम दो का चयन करेगा।
• न तो चर में 0 है: न्यूनतम मान चुना गया है।

उस लाइन को लिखने__ बदलने और बदलने के लिए व्यवहार को ठीक करेगा:

• केवल एक या न तो चर में 0 है: गैर-शून्य मान चुना गया है।
• न तो चर में 0 है: न्यूनतम मान चुना गया है।

स्निपेट 2

V547 अभिव्यक्ति हमेशा सच है। संभवतः '&&' ऑपरेटर का उपयोग यहां किया जाना चाहिए। डिस्क। १४१ ९

 static RD_NTSTATUS disk_device_control(RD_NTHANDLE handle, uint32 request, STREAM in, STREAM out) { .... if (((request >> 16) != 20) || ((request >> 16) != 9)) return RD_STATUS_INVALID_PARAMETER; .... } 

फिर, यह गलत ऑपरेटर के उपयोग की समस्या की तरह दिखता है - या तो || इसके बजाय && या == के बजाय ! = क्योंकि चर एक ही समय में 20 और 9 मानों को संग्रहीत नहीं कर सकता है।

असीमित स्ट्रिंग की नकल

V512 ' स्प्रिंटफ ' फ़ंक्शन के कॉल से बफर 'फ़ुलपैथ' का अतिप्रवाह होगा। disk.c 1257

 RD_NTSTATUS disk_query_directory(....) { .... char *dirname, fullpath[PATH_MAX]; .... /* Get information for directory entry */ sprintf(fullpath, "%s/%s", dirname, pdirent->d_name); .... } 

यदि आप फ़ंक्शन को अंत तक अनुसरण कर सकते हैं, तो आप देखेंगे कि कोड ठीक है, लेकिन यह एक दिन टूट सकता है: बस एक लापरवाह परिवर्तन बफर ओवरफ्लो के साथ समाप्त हो जाएगा क्योंकि स्प्रिंटफ किसी भी तरह से सीमित नहीं है, इसलिए कंक्रीटिंग पथ सरणी सीमाओं से परे निष्पादन ले सकता है। हम इस कॉल को स्निपरफ (पूर्णपथ, PATH_MAX, ....) के साथ बदलने की सलाह देते हैं।

निरर्थक स्थिति

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: Add> 0. scard.c 507

 static void inRepos(STREAM in, unsigned int read) { SERVER_DWORD add = 4 - read % 4; if (add < 4 && add > 0) { .... } } 

ऐड> 0 चेक से कोई फ़र्क नहीं पड़ता क्योंकि वेरिएबल हमेशा शून्य से अधिक होगा क्योंकि रीड 4% शेष रहता है, जो कभी भी 4 के बराबर नहीं होगा।

xrdp

xrdp एक ओपन-सोर्स RDP सर्वर है। परियोजना में दो भाग होते हैं:

• xrdp - प्रोटोकॉल कार्यान्वयन। यह अपाचे 2.0 के तहत जारी किया गया है।
• xorgxrdp - xorgp के साथ उपयोग किए जाने वाले Xorg ड्राइवरों का एक संग्रह। यह X11 के तहत जारी किया गया है (MIT की तरह, लेकिन विज्ञापन में उपयोग निषिद्ध है)

विकास rdesktop और FreeRDP पर आधारित है। प्रारंभ में, ग्राफिक्स के साथ काम करने में सक्षम होने के लिए, आपको RDP समर्थन, X11rdp के साथ एक अलग VNC सर्वर या एक विशेष X11 सर्वर का उपयोग करना होगा, लेकिन जो कि Xorgxrdp की रिलीज़ के साथ अनावश्यक हो गए थे।

हम इस लेख में xorgxrdp के बारे में बात नहीं करेंगे।

पिछली परियोजना की तरह, xrdp एक छोटा है, जिसमें लगभग 80 KLOC शामिल हैं।

अधिक टाइपो

V525 कोड में समान ब्लॉकों का संग्रह होता है। 87, 88, 89 की पंक्तियों में 'r', 'g', 'r' की जाँच करें। rxxencode_rgb_to_yuv.c 87

 static int rfx_encode_format_rgb(const char *rgb_data, int width, int height, int stride_bytes, int pixel_format, uint8 *r_buf, uint8 *g_buf, uint8 *b_buf) { .... switch (pixel_format) { case RFX_FORMAT_BGRA: .... while (x < 64) { *lr_buf++ = r; *lg_buf++ = g; *lb_buf++ = r; // <= x++; } .... } .... } 

यह कोड librfxcodec लाइब्रेरी से आता है, जो RemoteFX के साथ काम करने के लिए jpeg2000 कोडेक को लागू करता है। "रेड" कलर चैनल को दो बार पढ़ा जाता है, जबकि "ब्लू" चैनल को बिल्कुल भी नहीं पढ़ा जाता है। इस तरह की कमी आमतौर पर कॉपी-पेस्ट के उपयोग के परिणामस्वरूप होती है।

समान फ़ंक्शन rfx_encode_format_argb में समान बग पाया गया था:

V525 कोड में समान ब्लॉकों का संग्रह होता है। आइटम 'a', 'r', 'g', 'r' को लाइनों 260, 261, 262, 263 पर जांचें। rfxencode_rgb_to_yuv.c 260

 while (x < 64) { *la_buf++ = a; *lr_buf++ = r; *lg_buf++ = g; *lb_buf++ = r; x++; } 

ऐलान की घोषणा

V557 ऐरे ओवररन संभव है। 'I - 8' इंडेक्स का मान 129 तक पहुंच सकता है। genkeymap.c 142

 // evdev-map.c int xfree86_to_evdev[137-8+1] = { .... }; // genkeymap.c extern int xfree86_to_evdev[137-8]; int main(int argc, char **argv) { .... for (i = 8; i <= 137; i++) /* Keycodes */ { if (is_evdev) e.keycode = xfree86_to_evdev[i-8]; .... } .... } 

Genkeymap.c फ़ाइल में, सरणी को कार्यान्वयन से निहित 1 तत्व से कम घोषित किया गया है। हालांकि, कोई बग नहीं होगा, क्योंकि evdev-map.c फ़ाइल सही आकार संग्रहीत करता है, इसलिए कोई सरणी नहीं होगी, जो इसे एक वास्तविक त्रुटि के बजाय मामूली दोष बनाती है।

गलत तुलना

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: (cap_len <0)। xrdp_caps.c 616

 // common/parse.h #if defined(B_ENDIAN) || defined(NEED_ALIGN) #define in_uint16_le(s, v) do \ .... #else #define in_uint16_le(s, v) do \ { \ (v) = *((unsigned short*)((s)->p)); \ (s)->p += 2; \ } while (0) #endif int xrdp_caps_process_confirm_active(struct xrdp_rdp *self, struct stream *s) { int cap_len; .... in_uint16_le(s, cap_len); .... if ((cap_len < 0) || (cap_len > 1024 * 1024)) { .... } .... } 

अहस्ताक्षरित लघु के एक चर का मान प्रकार int के एक चर में पढ़ा जाता है और फिर नकारात्मक होने के लिए जाँच की जाती है, जो आवश्यक नहीं है क्योंकि एक अहस्ताक्षरित प्रकार से बड़े प्रकार में पढ़ा गया मान कभी भी ऋणात्मक नहीं बन सकता है।

निरर्थक जाँच

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: (bpp! = 16)। libxrdp.c 704

 int EXPORT_CC libxrdp_send_pointer(struct xrdp_session *session, int cache_idx, char *data, char *mask, int x, int y, int bpp) { .... if ((bpp == 15) && (bpp != 16) && (bpp != 24) && (bpp != 32)) { g_writeln("libxrdp_send_pointer: error"); return 1; } .... } 

नहीं के बराबर चेक आवश्यक नहीं है क्योंकि पहला चेक काम करता है। प्रोग्रामर शायद उपयोग करने जा रहा था || गलत तर्कों को फ़िल्टर करने के लिए ऑपरेटर।

निष्कर्ष

आज की जाँच में किसी भी महत्वपूर्ण कीड़े का पता नहीं चला, लेकिन इसने छोटे-मोटे दोषों का एक गुच्छा प्रकट किया। उस ने कहा, इन परियोजनाओं, के रूप में छोटे, वे अभी भी कई प्रणालियों में उपयोग किया जाता है और इसलिए, कुछ चमकाने की जरूरत है। एक छोटी परियोजना में जरूरी टन नहीं होना चाहिए, इसलिए केवल छोटी परियोजनाओं पर विश्लेषक का परीक्षण मज़बूती से इसकी प्रभावशीलता का मूल्यांकन करने के लिए पर्याप्त नहीं है। इस विषय पर " संख्याओं द्वारा पुष्टि की गई भावनाओं " लेख में अधिक विस्तार से चर्चा की गई है ।

पीवीएस-स्टूडियो का डेमो संस्करण हमारी वेबसाइट पर उपलब्ध है।