PVS-Studio विश्लेषक का उपयोग करके rdesktop और xrdp को मान्य करना

आरडीपी प्रोटोकॉल के साथ काम करने के लिए खुले स्रोत कार्यक्रमों की जाँच करने पर लेखों की एक श्रृंखला में यह दूसरी समीक्षा है। इसमें, हम rdesktop क्लाइंट और xrdp सर्वर पर विचार करेंगे।

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

लेख केवल उन त्रुटियों को प्रस्तुत करता है जो मुझे दिलचस्प लगे। हालांकि, परियोजनाएं छोटी हैं, इसलिए कुछ त्रुटियां थीं :)।

नोट। फ्रीआरडीपी परियोजना की जांच के बारे में पिछला लेख यहां पाया जा सकता है ।

rdesktop

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

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

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

अगम्य कोड

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); } .... } 

इस स्थिति में कोड स्निपेट फ़ाइल से बफर तक फ़ाइल समाप्त होने तक पढ़ता है। हालांकि, यहां कोई त्रुटि नहीं है: यदि कुछ गलत हो जाता है, तो पढ़ा -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++; } .... } 

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

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

शुद्धिपत्र

टुकड़ा करना १

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; // <= .... } 

शायद इस कोड के लेखक ने भ्रमित किया || और && प्रदान किया गया। लिखने के लिए संभावित विकल्पों पर विचार करें और change_time :

• दोनों चर 0 हैं: इस मामले में, हम दूसरी शाखा में जाते हैं: mod_time चर हमेशा 0 होगा चाहे वह निम्न स्थिति का हो।
• चरों में से एक 0 है: mod_time 0 होगा (बशर्ते कि दूसरे चर का एक गैर-नकारात्मक मान हो), क्योंकि MIN दोनों विकल्पों में से सबसे छोटे का चयन करेगा।
• दोनों चर 0 के बराबर नहीं हैं: हम न्यूनतम मूल्य का चयन करते हैं।

जब एक शर्त को बदलने के साथ write_time && change_time, व्यवहार सही लगेगा:

• एक या दोनों वैरिएबल 0 के बराबर नहीं हैं: नॉनज़रो वैल्यू चुनें।
• दोनों चर 0 के बराबर नहीं हैं: हम न्यूनतम मूल्य का चयन करते हैं।

टुकड़ा करना २

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); .... } 

फ़ंक्शन पर विचार करते समय, यह पूरी तरह से स्पष्ट हो जाएगा कि यह कोड समस्याओं का कारण नहीं है। हालांकि, वे भविष्य में उत्पन्न हो सकते हैं: एक लापरवाह परिवर्तन, और हम एक बफर अतिप्रवाह प्राप्त करते हैं - स्प्रिंटफ कुछ भी सीमित नहीं है, इसलिए जब पथ को बदलते हुए, हम सरणी की सीमाओं से परे जा सकते हैं। इस कॉल को snprintf (fullpath, 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 सर्वर कार्यान्वयन है। परियोजना 2 भागों में विभाजित है:

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

प्रोजेक्ट डेवलपमेंट rdesktop और FreeRDP के परिणामों पर आधारित है। प्रारंभ में, मुझे ग्राफिक्स के साथ काम करने के लिए एक अलग वीएनसी सर्वर का उपयोग करना पड़ा, या आरडीपी समर्थन के साथ एक विशेष X11 सर्वर - X11rdp, लेकिन xorgxrdp के आगमन के साथ, उन्हें अब ज़रूरत नहीं थी।

इस लेख में, हम xorgxrdp पर स्पर्श नहीं करेंगे।

पिछले परियोजना की तरह, xrdp परियोजना बहुत छोटी है और इसमें लगभग 80 हजार लाइनें हैं।

अधिक टाइपो

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]; .... } .... } 

इन दो फ़ाइलों में सरणी की घोषणा और परिभाषा असंगत है - आकार में 1. भिन्न होता है। हालांकि, कोई त्रुटि नहीं होती है - सही आकार ईवादेव-मैपसी फ़ाइल में निर्दिष्ट किया गया है, इसलिए सीमा से बाहर निकलने का कोई रास्ता नहीं है। तो यह सिर्फ एक दोष है जिसे ठीक करना आसान है।

अवैध तुलना

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; } .... } 

असमानता के लिए जाँच का यहाँ मतलब नहीं है, क्योंकि हमारे पास पहले से ही शुरुआत है। यह संभावना है कि यह एक टाइपो है और डेवलपर इसका उपयोग करना चाहता है || अमान्य तर्कों को फ़िल्टर करने के लिए।

निष्कर्ष

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

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

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई लारिन। PVS-Studio के साथ rdesktop और xrdp की जाँच करना