Wireshark 3.x: macOS कोड विश्लेषण और बग समीक्षा

Wireshark Foundation ने लोकप्रिय नेटवर्क ट्रैफ़िक विश्लेषक - Wireshark 3.0.0 का अंतिम स्थिर संस्करण जारी किया है। नई रिलीज ने कई बगों को ठीक किया, नए प्रोटोकॉल का विश्लेषण करने की क्षमता को लागू किया और विनपैक ड्राइवर को एनपैक के साथ बदल दिया। यहां घोषणा का उद्धरण समाप्त होता है और परियोजना में बग पर हमारा लेख शुरू होता है। रिलीज से पहले, उन्हें स्पष्ट रूप से अपर्याप्त रूप से सही किया गया था। आइए कुछ सुधार करें ताकि एक नया रिलीज करने का एक कारण हो :)।

परिचय

Wireshark नेटवर्क ट्रैफ़िक को कैप्चर और विश्लेषण करने के लिए एक प्रसिद्ध उपकरण है। कार्यक्रम ज्ञात प्रोटोकॉल के विशाल बहुमत के साथ काम करता है, इसमें एक स्पष्ट और तार्किक ग्राफिकल इंटरफ़ेस, एक शक्तिशाली फिल्टर सिस्टम है। विंडसरक - क्रॉस-प्लेटफ़ॉर्म, ओएस में काम करता है जैसे: विंडोज, लिनक्स, मैकओएस, सोलारिस, फ्रीबीएसडी, नेटबीएसडी और कई अन्य।

त्रुटियों की खोज करने के लिए, हमने PVS-Studio स्थैतिक विश्लेषक का उपयोग किया। स्रोत कोड का विश्लेषण करने के लिए, आपको पहले कुछ ऑपरेटिंग सिस्टम में प्रोजेक्ट को संकलित करना होगा। पसंद न केवल परियोजना के क्रॉस-प्लेटफ़ॉर्म प्रकृति के कारण, बल्कि विश्लेषक के क्रॉस-प्लेटफ़ॉर्म प्रकृति के कारण भी बहुत अच्छी थी। परियोजना के विश्लेषण के लिए, मैंने macOS को चुना। विश्लेषक विंडोज और लिनक्स पर भी लॉन्च किया जा सकता है।

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

इसके अलावा, ऐसे आवेषण कोड में गुणवत्ता नहीं जोड़ते हैं:

/* Input file: packet-acse-template.c */ #line 1 "./asn1/acse/packet-acse-template.c" 

पूरी परियोजना में उनमें से 1000 से अधिक हैं। इस तरह के आवेषण विश्लेषक के लिए वांछित फ़ाइल के साथ उत्पन्न चेतावनी की तुलना करना मुश्किल बनाते हैं। लेकिन मुझे यकीन है कि सामान्य डेवलपर्स को इस तरह के कोड का समर्थन नहीं मिलता है।

शुद्धिपत्र

चेतावनी १

V641 आवंटित स्मृति बफ़र का आकार तत्व आकार का एक से अधिक नहीं है। mate_setup.c 100

 extern mate_cfg_gog* new_gogcfg(mate_config* mc, gchar* name) { mate_cfg_gog* cfg = (mate_cfg_gog *)g_malloc(sizeof(mate_cfg_gop)); .... } 

दो प्रकार की संरचनाएं हैं: mate_cfg_gog और mate_cfg_gop , वे बहुत समान हैं, लेकिन समान नहीं हैं। सबसे अधिक संभावना है, इस कोड के टुकड़े में फ़ंक्शन को मिलाया गया था, जो कि पॉइंटर के बाद मेमोरी एक्सेस के दौरान प्रोग्राम में संभावित त्रुटियों से भरा हुआ है।

निम्नलिखित भ्रमित डेटा संरचनाओं के स्निपेट हैं:

 typedef struct _mate_cfg_gog { gchar* name; GHashTable* items; guint last_id; GPtrArray* transforms; LoAL* keys; AVPL* extra; float expiration; gop_tree_mode_t gop_tree_mode; gboolean show_times; .... } mate_cfg_gog; typedef struct _mate_cfg_gop { gchar* name; guint last_id; GHashTable* items; GPtrArray* transforms; gchar* on_pdu; AVPL* key; AVPL* start; AVPL* stop; AVPL* extra; float expiration; float idle_timeout; float lifetime; gboolean drop_unassigned; gop_pdu_tree_t pdu_tree_mode; gboolean show_times; .... } mate_cfg_gop; 

चेतावनी २

V519 'HDR_TCP.dest_port' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 495, 496. text_import.c 496

 void write_current_packet (void) { .... HDR_TCP.source_port =isOutbound ? g_htons(hdr_dest_port):g_htons(hdr_src_port); HDR_TCP.dest_port = isOutbound ? g_htons(hdr_src_port) :g_htons(hdr_dest_port); HDR_TCP.dest_port = g_htons(hdr_dest_port); .... } 

अंतिम पंक्ति में, HDR_TCP.dest_port चर का केवल परिकलित मान अपुष्ट है ।

तार्किक त्रुटियाँ

इस खंड में मैं सशर्त बयानों में त्रुटियों के कुछ उदाहरण दूंगा, और वे सभी एक दूसरे से मौलिक रूप से अलग होंगे।

चेतावनी १

V547 अभिव्यक्ति 'दिशा == 0' हमेशा झूठी होती है। पैकेट- adb.c 291

 #define P2P_DIR_RECV 1 #define P2P_DIR_SENT 0 static void save_command(....) { .... if ( service_data && service_data->remote_id == 0 && direction == P2P_DIR_RECV) { if (direction == P2P_DIR_SENT) { service_data->remote_id = arg1; // unreachable code } else { service_data->remote_id = arg0; } .... } .... } 

बाहरी स्थिति में, दिशा चर की तुलना निरंतर P2P_DIR_RECV से की जाती है । AND ऑपरेटर के माध्यम से अभिव्यक्ति लिखने का अर्थ है कि जब आंतरिक स्थिति तक पहुँच जाता है, तो दिशा चर का मान अन्य स्थिर P2P_DIR_SENT के बराबर नहीं होगा।

चेतावनी २

V590 '(प्रकार == 0x1) का निरीक्षण करने पर विचार करें || (प्रकार! = 0x4) 'अभिव्यक्ति। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। पैकेट- fcsb3.c 686

 static int dissect_fc_sbccs (....) { .... else if ((type == FC_SBCCS_IU_CMD_HDR) || (type != FC_SBCCS_IU_CMD_DATA)) { .... } 

इस कोड के टुकड़े की त्रुटि यह है कि हालत का परिणाम केवल एक अभिव्यक्ति पर निर्भर करता है:

 (type != FC_SBCCS_IU_CMD_DATA) 

चेतावनी ३

V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। snort-config.c 40

 static char *skipWhiteSpace(char *source, int *accumulated_offset) { int offset = 0; /* Skip any leading whitespace */ while (source[offset] != '\0' && source[offset] == ' ') { offset++; } *accumulated_offset += offset; return source + offset; } 

सशर्त विवरण का परिणाम केवल अभिव्यक्ति के इस भाग पर निर्भर करेगा (स्रोत [ऑफसेट] == '') । चेक (स्रोत [ऑफसेट]! = '\ 0') निरर्थक है और सुरक्षित रूप से हटाया जा सकता है। यह एक वास्तविक गलती नहीं है, लेकिन अनावश्यक कोड को प्रोग्राम को पढ़ना और समझना मुश्किल हो जाता है, इसलिए इसे सरल करना बेहतर है।

चेतावनी ४

V547 अभिव्यक्ति 'eras_pos! = NULL' हमेशा सत्य होती है। reedsolomon.c 659

 int eras_dec_rs(dtype data[NN], int eras_pos[NN-KK], int no_eras) { .... if(eras_pos != NULL){ for(i=0;i<count;i++){ if(eras_pos!= NULL) eras_pos[i] = INDEX_TO_POS(loc[i]); } } .... } 

शायद हम अनावश्यक सत्यापन के साथ काम कर रहे हैं, और संभवत: एक टाइपो के साथ, और एक आईएफएस में, कुछ और जाँच की जानी चाहिए।

अजीब संपत्ति

चेतावनी १

V547 अभिव्यक्ति 'सब_डिसेक्टर्स! = NULL' हमेशा सत्य होता है। कैप्चर_डिसेक्टर्स। सीसी 129

 void capture_dissector_add_uint(....) { .... sub_dissectors = (struct capture_dissector_table*)g_hash_table_lookup(....); if (sub_dissectors == NULL) { fprintf(stderr, "OOPS: Subdissector \"%s\" not found ... \n", name); if (getenv("WIRESHARK_ABORT_ON_DISSECTOR_BUG") != NULL) abort(); return; } g_assert(sub_dissectors != NULL); // <= .... } 

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

चेतावनी २

V547 एक्सप्रेशन 'i <count' हमेशा सच होता है। पैकेट- netflow.c 10363

 static int dissect_v9_v10_template_fields(....) { .... count = tmplt_p->field_count[fields_type]; for(i=0; i<count; i++) { .... if (tmplt_p->fields_p[fields_type] != NULL) { DISSECTOR_ASSERT (i < count); // <= tmplt_p->fields_p[fields_type][i].type = type; tmplt_p->fields_p[fields_type][i].length = length; tmplt_p->fields_p[fields_type][i].pen = pen; tmplt_p->fields_p[fields_type][i].pen_str = pen_str; if (length != VARIABLE_LENGTH) {/ tmplt_p->length += length; } } .... } .... } 

यह स्पष्ट नहीं है कि फ़ंक्शन में एक मुखर क्यों है जो लूप से एक स्थिति को डुप्लिकेट करता है। शरीर में चक्र काउंटर नहीं बदलता है।

संकेत के साथ त्रुटियाँ

चेतावनी १

V595 nullptr के खिलाफ सत्यापित होने से पहले 'si-> conv' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 2135, 2144. पैकेट-smb2.c 2135

 static int dissect_smb2_fid(....) { .... g_hash_table_insert(si->conv->fids, sfi, sfi); // <= si->file = sfi; if (si->saved) { si->saved->file = sfi; si->saved->policy_hnd = policy_hnd; } if (si->conv) { // <= eo_file_info = (.... *)g_hash_table_lookup(si->conv->files,&policy_hnd); .... } .... } 

पॉइंटर si-> कन्टेन को पहले से जाँची जाने वाली कई लाइनों की जाँच की जाती है कि यह शून्य के बराबर है या नहीं।

चेतावनी २

V774 मेमोरी जारी होने के बाद 'प्रोटोज' पॉइंटर का उपयोग किया गया था। पैकेट- k12.c 311

 static gboolean k12_update_cb(void* r, char** err) { gchar** protos; .... for (i = 0; i < num_protos; i++) { if ( ! (h->handles[i] = find_dissector(protos[i])) ) { h->handles[i] = data_handle; h->handles[i+1] = NULL; g_strfreev(protos); *err = g_strdup_printf("Could not find dissector for: '%s'", protos[i]); return FALSE; } } .... } 

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

 *err = g_strdup_printf("Could not find dissector for: '%s'", protos[i]); g_strfreev(protos); 

स्मृति लीक

V773 'ptmpstr' पॉइंटर को मेमोरी जारी किए बिना दो बार मान दिया गया था। एक स्मृति रिसाव संभव है। idl2wrs.c 2436

 static void parsetypedefunion(int pass) { char tmpstr[BASE_BUFFER_SIZE], *ptmpstr; .... while(num_pointers--){ g_snprintf(tmpstr, BASE_BUFFER_SIZE, "%s_%s", ptmpstr, "unique"); FPRINTF(eth_code, "static int\n"); FPRINTF(eth_code, "....", tmpstr); FPRINTF(eth_code, "{\n"); FPRINTF(eth_code, " ....", ptmpstr, ti->str); FPRINTF(eth_code, " return offset;\n"); FPRINTF(eth_code, "}\n"); FPRINTF(eth_code, "\n"); ptmpstr=g_strdup(tmpstr); } .... } 

G_strdup फ़ंक्शन के बाद, आपको कुछ बिंदु पर g_free फ़ंक्शन को कॉल करना होगा। प्रस्तुत कोड के टुकड़े में, यह नहीं किया जाता है, और प्रत्येक पुनरावृत्ति पर लूप में रैम का एक नया टुकड़ा आवंटित किया जाता है। मल्टीपल मेमोरी लीक्स होती है।

समान कोड स्निपेट के लिए कुछ और चेतावनी:

• V773 'ptmpstr' पॉइंटर को मेमोरी जारी किए बिना दो बार मान दिया गया था। एक स्मृति रिसाव संभव है। idl2wrs.c 2447
• V773 'ptmpstr' पॉइंटर को मेमोरी जारी किए बिना दो बार मान दिया गया था। एक स्मृति रिसाव संभव है। idl2wrs.c 2713
• V773 'ptmpstr' पॉइंटर को मेमोरी जारी किए बिना दो बार मान दिया गया था। एक स्मृति रिसाव संभव है। idl2wrs.c 2728
• V773 'ptmpstr' पॉइंटर को मेमोरी जारी किए बिना दो बार मान दिया गया था। एक स्मृति रिसाव संभव है। idl2wrs.c 2732
• V773 'ptmpstr' पॉइंटर को मेमोरी जारी किए बिना दो बार मान दिया गया था। एक स्मृति रिसाव संभव है। idl2wrs.c 2745

दुर्भाग्य से, कोड में कई अन्य समान स्थान हैं जहां मेमोरी को मुक्त नहीं किया गया है।

अनेक वस्तुओं का संग्रह

चेतावनी १

V535 चर 'i' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। चेक लाइनें: 7716, 7798. पैकेट-ओपा-मैड.क। 7798

 /* Parse GetVFInfo MAD from the Performance Admin class. */ static gint parse_GetVFInfo(....) { .... for (i = 0; i < records; i++) { // <= line 7716 .... for (i = 0; i < PM_UTIL_BUCKETS; i++) { // <= line 7748 GetVFInfo_Util_Stats_Bucket_item = proto_tree_add_item(....); proto_item_set_text(....); local_offset += 4; } .... for (i = 0; i < PM_ERR_BUCKETS; i++) { // <= line 7798 GetVFInfo_Error_Stats_Bucket_item = proto_tree_add_item(....); proto_item_set_text(....); local_offset += 4; .... } .... } .... } 

एक बहुत लंबे फ़ंक्शन में, डेवलपर्स साहसपूर्वक लूप काउंटर के मूल्य को बदलते हैं, और कई बार ऐसा करते हैं। यह कहना मुश्किल है कि यह गलती है या नहीं, लेकिन परियोजना में लगभग 10 ऐसे चक्र हैं।

चेतावनी २

V763 पैरामीटर 'आइटम' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। पैकेट- cdma2k.c 1324

 static void cdma2k_message_ORDER_IND(proto_item *item, ....) { guint16 addRecLen = -1, ordq = -1, rejectedtype = -1; guint16 l_offset = -1, rsc_mode_ind = -1, ordertype = -1; proto_tree *subtree = NULL, *subtree1 = NULL; item = proto_tree_add_item(tree,hf_cdma2k_OrderIndMsg, tvb, ....); // <= subtree = proto_item_add_subtree(item, ett_cdma2k_subtree1); .... } 

आइटम पॉइंटर जो फ़ंक्शन को लेता है, तुरंत दूसरे मूल्य से फ़्री किया जाता है। यह बहुत ही संदिग्ध है। इसके अलावा, कोड में कई दर्जन ऐसे स्थान हैं, इसलिए यह कहना मुश्किल है कि यह कोई गलती है या नहीं। मैं एक अन्य बड़े प्रोजेक्ट में पहले इसी तरह के कोड से मिला था, यह सही कोड था, बस किसी ने फ़ंक्शन के इंटरफ़ेस को बदलने की हिम्मत नहीं की।

चेतावनी ३

V762 यह संभव है कि एक आभासी फ़ंक्शन गलत तरीके से ओवरराइड किया गया था। फंक्शन 'हैडरडैटा' के तीसरे तर्क को व्युत्पन्न वर्ग 'पैकेटलाइस्टमॉडल' और बेस क्लास 'क्यूएब्रेट इटेममॉडल' में देखें। packet_list_model.h 48

 QVariant QAbstractItemModel::headerData(int section, Qt::Orientation orientation, int role = Qt::DisplayRole) const // <= class PacketListModel : public QAbstractItemModel { Q_OBJECT public: .... QVariant headerData(int section, Qt::Orientation orientation, int role = Qt::DisplayRole | Qt::ToolTipRole) const; // <= .... }; 

विश्लेषक ने शीर्ष लेख दाता फ़ंक्शन के गलत अधिभार का पता लगाया। भूमिका पैरामीटर के लिए फ़ंक्शंस का एक अलग डिफ़ॉल्ट मान होता है। यह प्रोग्रामर से अपेक्षित व्यवहार नहीं हो सकता है।

चेतावनी ४

V610 अपरिभाषित व्यवहार। शिफ्ट ऑपरेटर '>>' की जाँच करें। दायाँ ऑपरेंड ('बिटशिफ्ट' = [0..64]) प्रमोटेड लेफ्ट ऑपरेंड के बिट्स में लंबाई से अधिक या बराबर होता है। प्रोटो। 109 109

 static gboolean proto_item_add_bitmask_tree(...., const int len, ....) { .... if (len < 0 || len > 8) g_assert_not_reached(); bitshift = (8 - (guint)len)*8; available_bits = G_GUINT64_CONSTANT(0xFFFFFFFFFFFFFFFF) >> bitshift; .... } 

64-बिट शिफ्ट में भाषा मानक के अनुसार अपरिभाषित व्यवहार होगा।

बल्कि, सही कोड इस तरह होना चाहिए:

 if (bitshift == 64) available_bits = 0; else available_bits = G_GUINT64_CONSTANT(0xFFFFFFFFFFFFFFFF) >> bitshift; 

निष्कर्ष

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

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

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: Svyatoslav Razmyslov। Wireshark 3.x: macOS और त्रुटियों की समीक्षा के तहत कोड विश्लेषण