Wireshark 3.x: macOS और त्रुटियों की समीक्षा के तहत कोड विश्लेषण

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

चलिए अब एक नया रिलीज़ करने के लिए एक मकसद देने के लिए अभी से ही हॉटफ़िक्स इकट्ठा करते हैं :)।

परिचय

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

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

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

ऐसे आवेषण भी कोड गुणवत्ता को बढ़ावा नहीं देते हैं:

/* 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; 

निष्कर्ष

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

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