System and method for auto repairing vulnerable code program fragments of a software

Abstract

This disclosure provides system and method for auto repairing vulnerable code program fragments of a software. The present disclosure addresses problems of conventional approaches which are dependent on test cases. In the present disclosure, vulnerabilities in an input application are identified and repaired. First, a plurality of vulnerability detection rules are executed against an application in binary form (i.e., input application) and a plurality of vulnerable code fragments are identified. Post identification of the plurality of vulnerable code fragments, a mapping is created from the application in binary form to its source code files. Post mapping, paths capturing different application functionalities are extracted. Subsequently, a plurality of vulnerable source code program fragments are extracted and auto repair rules are applied on entire application functionality. As a result of execution of the auto repair rules, the plurality of vulnerable source code program fragments are replaced with safe code fragments. [To be published with FIG. 2]

Description

TECHNICAL FIELD

[001] The disclosure herein generally relates to the field of software, and,more particularly, to systems and methods for auto repairing vulnerable codeprogram fragments of a software.BACKGROUND

[002] With the expansion of software industry, software programming hasbecome an integral of multiple applications in multiple industries. However,vulnerability of software code programs in software is an issue of concerns as itmay lead to network intrusion and compromise security of the software. Autocorrection of the software vulnerability is of considerable interest to enterprises asthey try to minimize software maintenance burden. There exist few conventionalapproaches for auto correction of the software vulnerability that include test drivenapproaches or Deep Learning (DL) based approaches to automatically patch avulnerable code.

[003] Test driven approaches require a test suite containing one failing testcase along with a fault localization strategy. Auto repair process in the test drivenapproaches involves generating different patches that pass all testcases of given testsuite. Thus, test driven approaches are dependent on the test suite with one failingtest case for vulnerability correction. Enterprise applications may have test cases,but they are mostly limited to functional testing and figuring out test cases only fordetecting a vulnerability is a challenging task and requires expertise.

[004] A solution for eliminating the need of test suite proposed in testdriven approaches is provided by DL based approaches. The DL based approachesgenerate patches for vulnerable code without requiring test suite. However, theyneed a comprehensive dataset to train DL model. Moreover, DL based approachesare susceptible to encoding of input test programs. Every DL based approachdefines a way to process only relevant parts of programs in a given dataset andaccuracy of a patch generation depends on a preprocessing step before generatingembeddings for dataset programs. Further, DL based approaches do not generate aunique patch for a vulnerability rather they generate a set of candidate patches. Thisrequires software engineers to manually inspect each one of them to figure outsuitable candidate if there exists any.SUMMARY

[005] Embodiments of the present disclosure present technologicalimprovements as solutions to one or more of the above-mentioned technicalproblems recognized by the inventors in conventional systems. For example, in oneembodiment, a processor implemented method is provided. The processorimplemented method, comprising receiving, via an input / output interface, anapplication in binary form, and a set of predefined vulnerability detection rules asan input; detecting, via a first module executed by one or more hardware processors,a plurality of vulnerable program fragments in the received application in binaryform based on the set of predefined vulnerability detection rules; creating, via asecond module executed by the one or more hardware processors, a mappingbetween the application in binary form and a plurality of source code filescorresponding to the application in binary form to identify a plurality of vulnerablesource code program fragments; and performing, via a third module executed bythe one or more hardware processors, an auto repairing process on each of theidentified plurality of vulnerable source code program fragments to obtain aplurality of safe source code program fragments, wherein the auto repairing processcomprises: extracting, one or more paths representing a functionality aspect of theapplication in binary form and a plurality of vulnerable program statements for eachvulnerable source code program fragment from the plurality of vulnerable sourcecode program fragments in the application in binary form based on the createdmapping; applying, a functional ordered auto repair rule from a plurality offunctional ordered auto repair rules in accordance with a plurality of predefinedcriterions to each of the plurality of vulnerable program statements of each pathfrom the one or more paths; computing, an effect of applying the functional orderedauto repair rule on a plurality of non-vulnerable program statements within a firstset of procedures from a set of procedures associated with each of the one or morepaths, wherein the functional ordered auto repair rule utilizes one or more repairstrategies, and wherein one or more inconsistencies are generated in the plurality ofnon-vulnerable program statements within the first set of procedures from the setof procedures associated with each of the one or more paths when the one or morerepair strategies are used; resolving, the one or more inconsistency generated in theplurality of non-vulnerable program statements within the first set of proceduresfrom the set of procedures associated with each of the one or more paths; anditeratively computing, an effect of use of the one or more repair strategies on asecond set of the procedures from the set of procedures and resolving the one ormore inconsistency generated in the second set of procedures from the set ofprocedures associated with each of the one or more paths.

[006] In another aspect, a system is provided. The system comprising amemory storing instructions; one or more communication interfaces; and one ormore hardware processors coupled to the memory via the one or morecommunication interfaces, wherein the one or more hardware processors areconfigured by the instructions to: receive, an application in binary form and a set ofpredefined vulnerability detection rules as an input; detect, a plurality of vulnerableprogram fragments in the received application in binary form based on the set ofpredefined vulnerability detection rules; create, a mapping between the applicationin binary form and a plurality of source code files corresponding to the applicationin binary form to identify a plurality of vulnerable source code program fragments;and perform, an auto repairing process on each of the identified plurality ofvulnerable source code program fragments to obtain a plurality of safe source codeprogram fragments, wherein the auto repairing process comprises: extracting, oneor more paths representing a functionality aspect of the application in binary formand a plurality of vulnerable program statements for each vulnerable source codeprogram fragment from the plurality of vulnerable source code program fragmentsin the application in binary form based on the created mapping; applying, afunctional ordered auto repair rule from a plurality of functional ordered auto repairrules in accordance with a plurality of predefined criterions to each of the pluralityof vulnerable program statements of each path from the one or more paths;computing, an effect of applying the functional ordered auto repair rule on aplurality of non-vulnerable program statements within a first set of procedures froma set of procedures associated with each of the one or more paths, wherein thefunctional ordered auto repair rule utilizes one or more repair strategies, andwherein one or more inconsistencies are generated in the plurality of non-vulnerableprogram statements within the first set of procedures from the set of proceduresassociated with each of the one or more paths when the one or more repair strategiesare used; resolving, the one or more inconsistency generated in the plurality of nonvulnerableprogram statements within the first set of procedures from the set ofprocedures associated with each of the one or more paths; and iterativelycomputing, an effect of use of the one or more repair strategies on a second set ofthe procedures from the set of procedures and resolving the one or moreinconsistency generated in the second set of procedures from the set of proceduresassociated with each of the one or more paths.

[007] In yet another aspect, a non-transitory computer readable mediumis provided. The non-transitory computer readable medium are configured byinstructions for receiving, an application in binary form, and a set of predefinedvulnerability detection rules as an input; detecting, a plurality of vulnerableprogram fragments in the received application in binary form based on the set ofpredefined vulnerability detection rules; creating, a mapping between theapplication in binary form and a plurality of source code files corresponding to theapplication in binary form to identify a plurality of vulnerable source code programfragments; and performing, an auto repairing process on each of the identifiedplurality of vulnerable source code program fragments to obtain a plurality of safesource code program fragments, wherein the auto repairing process comprises:extracting, one or more paths representing a functionality aspect of the applicationin binary form and a plurality of vulnerable program statements for each vulnerablesource code program fragment from the plurality of vulnerable source code programfragments in the application in binary form based on the created mapping; applying,a functional ordered auto repair rule from a plurality of functional ordered autorepair rules in accordance with a plurality of predefined criterions to each of theplurality of vulnerable program statements of each path from the one or more paths;computing, an effect of applying the functional ordered auto repair rule on aplurality of non-vulnerable program statements within a first set of procedures froma set of procedures associated with each of the one or more paths, wherein thefunctional ordered auto repair rule utilizes one or more repair strategies, andwherein one or more inconsistencies are generated in the plurality of non-vulnerableprogram statements within the first set of procedures from the set of proceduresassociated with each of the one or more paths when the one or more repair strategiesare used; resolving, the one or more inconsistency generated in the plurality of nonvulnerableprogram statements within the first set of procedures from the set ofprocedures associated with each of the one or more paths; and iterativelycomputing, an effect of use of the one or more repair strategies on a second set ofthe procedures from the set of procedures and resolving the one or moreinconsistency generated in the second set of procedures from the set of proceduresassociated with each of the one or more paths.

[008] In accordance with an embodiment of the present disclosure, thefunctionality aspect is characterized by a functional group attribute and an orderattribute.

[009] In accordance with an embodiment of the present disclosure, theplurality of predefined criterions include (i) determining type of each of theplurality of vulnerable program statements (ii) determining a functional orderedauto repair rule from the plurality of functional ordered auto repair rules matchingto each of the plurality of vulnerable program statements, and (iii) determining arule type of the functional ordered auto repair rule from the plurality of functionalordered auto repair rules matching to each of the plurality of vulnerable programstatements.

[010] In accordance with an embodiment of the present disclosure, the firstset of procedures represents a set of vulnerability located procedures.

[011] In accordance with an embodiment of the present disclosure, thesecond set of procedures represents a set of non-vulnerability located procedures.

[012] the one or more repair strategies are utilized based on the rule typeof the functional ordered auto repair rule from the plurality of functional orderedauto repair rules matching to each of the plurality of vulnerable program statements.

[013] It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory only and are notrestrictive of the invention, as claimed.BRIEF DESCRIPTION OF THE DRAWINGS

[014] The accompanying drawings, which are incorporated in andconstitute a part of this disclosure, illustrate exemplary embodiments and, togetherwith the description, serve to explain the disclosed principles:

[015] FIG. 1 illustrates an exemplary system for auto repairing vulnerablecode program fragments of a software program, according to some embodiments ofthe present disclosure.

[016] FIG. 2 is a functional block diagram for auto repairing vulnerablecode program fragments of a software, using the system of FIG. 1, according tosome embodiments of the present disclosure.

[017] FIG. 3 illustrates an exemplary flow diagram illustrating a methodfor auto repairing vulnerable code program fragments of a software, using thesystem of FIG. 1, in accordance with some embodiments of the present disclosure.

[018] FIGS. 4A and 4B depict two sample codes taken from a sampleapplication for key generation and encryption functions for auto repairingvulnerable code program fragments of a software, in accordance with someembodiments of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTS

[019] Exemplary embodiments are described with reference to theaccompanying drawings. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Whereverconvenient, the same reference numbers are used throughout the drawings to referto the same or like parts. While examples and features of disclosed principles aredescribed herein, modifications, adaptations, and other implementations arepossible without departing from the scope of the disclosed embodiments. It isintended that the following detailed description be considered as exemplary only,with the true scope being indicated by the following embodiments described herein.

[020] Auto correcting an application vulnerability is of considerableinterest to enterprises as they try to minimize the software maintenance burden. Fewconventional approaches propose solutions to automatically repair buggy programs.All proposed solutions include a well-defined setting which includes a set of testcases with at least one of them failing for a given buggy program. Further, allproposed solutions rely on a fault localization strategy, an approach to find out aroot cause for a bug. Once fault is localized then a solution tries to generate a variantof buggy program which may succeed on all test cases. Typically, mostconventional approaches attempt to delete or add or modify program statements anda simple deletion strategy may suffice for it. Other conventional approaches aremore involved using hybrid approach than others that rely on a simple deletionstrategy. However, these few conventional approaches do not produce correctoutput of testcases rather just assume the test case not failing as success. Further,auto correction of vulnerable software may not necessarily depend on faultlocalization as faults are encoded in rules given as input. Moreover, auto correctionof vulnerable software may need to add or update or delete multiple programstatements across methods to generate a new variant and hence, these conventionalapproaches are not useful.

[021] Recently, deep learning (DL) based approaches were used toautomatically repair software vulnerabilities. DL based approaches encode inputdataset of programs by generating embeddings and output a repaired program for agiven buggy program. However, performance of DL solutions rely heavily on whatcontext is considered while generating embeddings. Richer contexts generate betterquality embeddings at expense of huge training time. Many a times, the set of realenterprise applications are not available in an enterprise setting to train a givenmodel. Further, heterogenous nature of enterprise applications makes training andcode related challenges more severe. Moreover, DL based approaches generate aset of candidates and not a single program addressing a vulnerability. Hence, amanual intervention from a developer is unavoidable. Finally, some DL basedapproaches suffer from Out Of Vocabulary (OOV) and code related challenges suchas which part of code should be considered and how to process inputs.

[022] The present disclosure addresses unresolved problems of theconventional methods by removing the dependency on test cases through functionalordered rules when applied to application extract functionalities in form of paths.The method and system of the present disclosure generates a unique code fragmentavoiding a need for manual verification from a software developer to choose amongmultiple competing code fragments. The present disclosure does not require anymodel training and hence does not depend on availability of dataset. A state-of-theart(e.g., 'Tan, Hee Beng Kuan, and Juan Tiang Kow. "An approach for extractingcode fragments that implement functionality from source programs." Journal ofSoftware Maintenance and Evolution: Research and Practice 13, no. 1 (2001): 53-75.') discusses an approach to extract code fragments that implement afunctionality.

[023] The method of the present disclosure uses slicing to extractfragments along with program statements processing input / output of the software.A slicing based approach proposed in the above-mentioned state-of-the-art mayend up collecting program statements that may not belong to particular functionalityas backward slices are not precise. This problem is resolved in the present disclosureby using a functionality determination module that uses functional ordered rules togenerate order among program statements and subsequently among applicationprocedures to extract a path representing functionality. In context of the presentdisclosure, the expressions 'functional ordered rules', 'rules', ''auto repair rules,and 'functional ordered auto repair rules' may be interchangeably used throughoutthe description.

[024] Embodiments of the present disclosure provide system and methodfor auto repairing of vulnerable code program fragments of a software programapplication. In the method of the present disclosure, vulnerabilities in an inputapplication are identified and repaired. First, a plurality of vulnerability detectionrules are executed against an application in binary form (i.e., input application) anda plurality of vulnerable code fragments are identified. Post identification of theplurality of vulnerable code fragments, a mapping is created from the applicationin binary form to its source code files. Once mapping is in place, paths capturingdifferent application functionalities are extracted. Subsequently, a plurality ofvulnerable (i.e., unsafe) source code program fragments are extracted, and autocorrection rules are applied on an entire application functionality. As a result ofexecution of the auto correction rules, the plurality of vulnerable (i.e., unsafe)source code program fragments are replaced with safe code fragments. Differentcode replacement strategies are adopted in the present disclosure to correct theplurality of vulnerable (i.e., unsafe) source code program fragments. Many a times,code replacement strategies end up creating inconsistencies in the input application.The repair process is further initiated to address inconsistencies. More Specifically,the present disclosure describes the following:1. A functionality extraction approach to extract functionalities usingfunctional ordered preserving rules to eliminate dependency on testcases.2. A multi pass auto repair process correcting inconsistencies arising dueto changes made to a software while applying auto repair rules.3. A generation of unique functionality specific repaired program.

[025] Referring now to the drawings, and more particularly to FIGS. 1through 4B, where similar reference characters denote corresponding featuresconsistently throughout the figures, there are shown preferred embodiments andthese embodiments are described in the context of the following exemplary systemand / or method.

[026] FIG. 1 illustrates an exemplary system for auto repairing vulnerablecode program fragments of a software according to some embodiments of thepresent disclosure. In an embodiment, the system 100 includes or is otherwise incommunication with one or more hardware processors 104, communicationinterface device(s) or input / output (I / O) interface(s) 106, and one or more datastorage devices or memory 102 operatively coupled to the one or more hardwareprocessors 104. The one or more hardware processors 104, the memory 102, andthe I / O interface(s) 106 may be coupled to a system bus 108 or a similar mechanism.

[027] The I / O interface(s) 106 may include a variety of software andhardware interfaces, for example, a web interface, a graphical user interface, andthe like. The I / O interface(s) 106 may include a variety of software and hardwareinterfaces, for example, interfaces for peripheral device(s), such as a keyboard, amouse, an external memory, a plurality of sensor devices, a printer and the like.Further, the I / O interface(s) 106 may enable the system 100 to communicate withother devices, such as web servers and external databases.

[028] The I / O interface(s) 106 can facilitate multiple communicationswithin a wide variety of networks and protocol types, including wired networks, forexample, local area network (LAN), cable, etc., and wireless networks, such asWireless LAN (WLAN), cellular, or satellite. For the purpose, the I / O interface(s)106 may include one or more ports for connecting a number of computing systemswith one another or to another server computer. Further, the I / O interface(s) 106may include one or more ports for connecting a number of devices to one anotheror to another server.

[029] The one or more hardware processors 104 may be implemented asone or more microprocessors, microcomputers, microcontrollers, digital signalprocessors, central processing units, state machines, logic circuitries, and / or anydevices that manipulate signals based on operational instructions. Among othercapabilities, the one or more hardware processors 104 are configured to fetch andexecute computer-readable instructions stored in the memory 102. In the context ofthe present disclosure, the expressions 'processors' and 'hardware processors' maybe used interchangeably. In an embodiment, the system 100 can be implemented ina variety of computing systems, such as laptop computers, portable computer,notebooks, hand-held devices, workstations, mainframe computers, servers, anetwork cloud and the like.

[030] The memory 102 may include any computer-readable mediumknown in the art including, for example, volatile memory, such as static randomaccess memory (SRAM) and dynamic random access memory (DRAM), and / ornon-volatile memory, such as read only memory (ROM), erasable programmableROM, flash memories, hard disks, optical disks, and magnetic tapes. In anembodiment, the memory 102 includes a plurality of modules 102a and a repository102b for storing data processed, received, and generated by one or more of theplurality of modules 102a. The plurality of modules 102a may include routines,programs, objects, components, data structures, and so on, which perform particulartasks or implement particular abstract data types.

[031] The plurality of modules 102a may include programs or computerreadableinstructions or coded instructions that supplement applications orfunctions performed by the system 100. The plurality of modules 102a may also beused as, signal processor(s), state machine(s), logic circuitries, and / or any otherdevice or component that manipulates signals based on operational instructions.Further, the plurality of modules 102a can be used by hardware, by computerreadableinstructions executed by the one or more hardware processors 104, or bya combination thereof. In an embodiment, the plurality of modules 102a can includevarious sub-modules (not shown in FIG.1) such as a vulnerability detection module,a mapping creation module, functionality determination module, slicing module,intra procedure correction module, and inter procedure correction module. Further,the memory 102 may include information pertaining to input(s) / output(s) of eachstep performed by the processor(s) 104 of the system 100 and methods of the presentdisclosure.

[032] The repository 102b may include a database or a data engine.Further, the repository 102b amongst other things, may serve as a database orincludes a plurality of databases for storing the data that is processed, received, orgenerated as a result of the execution of the plurality of modules 102a. Althoughthe repository 102b is shown internal to the system 100, it will be noted that, inalternate embodiments, the repository 102b can also be implemented external to thesystem 100, where the repository 102b may be stored within an external database(not shown in FIG. 1) communicatively coupled to the system 100. The datacontained within such external database may be periodically updated. For example,new data may be added into the external database and / or existing data may bemodified and / or non-useful data may be deleted from the external database. In oneexample, the data may be stored in an external system, such as a LightweightDirectory Access Protocol (LDAP) directory and a Relational DatabaseManagement System (RDBMS). In another embodiment, the data stored in therepository 102b may be distributed between the system 100 and the externaldatabase.

[033] FIG. 2, with reference to FIG. 1, is a functional block diagram forauto repairing vulnerable code program fragments of a software, using the systemof FIG. 1, according to some embodiments of the present disclosure.

[034] FIG. 3, with reference to FIGS. 1 and 2, illustrates an exemplaryflow diagram illustrating a method for auto repairing vulnerable code programfragments of a software, using the system of FIG. 1, in accordance with someembodiments of the present disclosure.

[035] Referring to FIG. 3, in an embodiment, the system(s) 100 comprisesone or more data storage devices or the memory 102 operatively coupled to the oneor more hardware processors 104 and is configured to store instructions forexecution of steps of the method by the one or more processors 104. The steps ofthe method 200 of the present disclosure will now be explained with reference tocomponents of the system 100 of FIG. 1, the block diagram of FIG. 2, the flowdiagram as depicted in FIG. 3, , and one or more examples. Although steps of themethod 200 including process steps, method steps, techniques or the like may bedescribed in a sequential order, such processes, methods and techniques may beconfigured to work in alternate orders. In other words, any sequence or order ofsteps that may be described does not necessarily indicate a requirement that thesteps be performed in that order. The steps of processes described herein may beperformed in any practical order. Further, some steps may be performedsimultaneously, or some steps may be performed alone or independently.

[036] In an embodiment, at step 202 of the present disclosure, aninput / output interface is configured to receive an application in binary form and aset of predefined vulnerability detection rules as an input.

[037] Further, at step 204 of the present disclosure, the one or morehardware processors 104 are configured to detect, via a first module executed byone or more hardware processors, a plurality of vulnerable program fragments inthe received application in binary form based on the set of predefined vulnerabilitydetection rules. It i s shown in FIG. 2 that the application in binary form and the setof vulnerability detection rules as received as input at first module. The first moduleis referred as vulnerability detection module. The vulnerability detection module110 of the system 100 detects a vulnerability in the application in binary form. Thevulnerability detection module 110 applies the set of vulnerability detection rulesagainst the application in binary form and detects vulnerabilities. To detectvulnerabilities, the vulnerability detection module 110 uses human craftedvulnerability detection rules. Mostly, a vulnerability detection rule representsvulnerable method signature. The vulnerability detection module 110 matchesbinary content of the application in binary form against a given vulnerabilitydetection rule to detect a vulnerability. If a match is found, then correspondingbinary fragment is marked as vulnerable.

[038] A vulnerability detection rule capturing unsafe cryptographic API(method signature) is further better understood by way of following pseudocodeprovided as example:VulDetRule {String className = "java.security.KeyPairGenerator";String methodName = "java.security.KeyPairGeneratorgetInstance(java.lang.String)";}Typically, the vulnerable program fragment (alternatively referred as vulnerablebinary code fragment) is a program statement ps in a procedure p.

[039] At step 206 of the present disclosure, the one or more hardwareprocessors 104 are configured to create, via a second module executed by the oneor more hardware processors, a mapping between the application in binary formand a plurality of source code files corresponding to the application in binary formto identify a plurality of vulnerable source code program fragments. The secondmodule is referred as a mapping creation module (also referred as Binary to Sourcemapping module). The present disclosure repair vulnerabilities automatically.However, the auto repair process in the binary form of application is impossible asthere are many transformations done by a compiler while converting source codeof an application into an optimal binary code. To mitigate side effects of thesetransformations, the auto repair process should work on the source code of theapplication. Moreover, application developers only understand source code. Givenall these constraints, a mapping from the application in binary form to itscorresponding source files is created.

[040] In an embodiment, at step 208 of the present disclosure, the one ormore hardware processors 104 are configured to perform, via a third moduleexecuted by the one or more hardware processors, an auto repairing process on eachof the identified plurality of vulnerable source code program fragments to obtain aplurality of safe source code program fragments. The module is referred as an autorepair module. In an embodiment, the auto repairing process comprises extracting,one or more paths representing a functionality aspect of the application in binaryform and a plurality of vulnerable program statements for each vulnerable sourcecode program fragment from the plurality of vulnerable source code programfragments in the application in binary form based on the created mapping. In anembodiment, the functionality aspect is characterized by a functional groupattribute and an order attribute. Further, a functional ordered auto repair rule froma plurality of functional ordered auto repair rules is applied to each of the pluralityof vulnerable program statements of each path from the one or more paths appliedin accordance with a plurality of predefined criterions.

[041] In another embodiment, the plurality of predefined criterions include(i) determining type of each of the plurality of vulnerable program statements (ii)determining a functional ordered rule from the plurality of functional ordered autorepair rules matching to each of the plurality of vulnerable program statements, and(iii) determining a rule type of the functional ordered rule from the plurality offunctional ordered auto repair rules matching to each of the plurality of vulnerableprogram statements.

[042] Furthermore, an effect of applying the functional ordered auto repairrule on a plurality of non-vulnerable program statements is computed within a firstset of procedures from a set of procedures associated with each of the one or morepaths. The first set of procedures represents a set of vulnerability locatedprocedures. Here, the functional ordered auto repair rule utilizes one or more repairstrategies. The one or more repair strategies are utilized based on the rule type ofthe functional ordered auto repair rule ordered rule from the plurality of functionalordered auto repair rules matching to each of the plurality of vulnerable programstatements.

[043] In yet another embodiment, one or more inconsistencies aregenerated in the plurality of non-vulnerable program statements within the first setof procedures from the set of procedures associated with each of the one or morepaths when the one or more repair strategies are used. The one or moreinconsistency generated in the plurality of non-vulnerable program statementswithin the first set of procedures from the set of procedures associated with each ofthe one or more paths are resolved. An effect of use of the one or more repairstrategies on a second set of the procedures from the set of procedures and resolvingthe one or more inconsistency generated in the second set of procedures from theset of procedures associated with each of the one or more paths is iterativelycomputed. The second set of procedures represents a set of non-vulnerabilitylocated procedures.

[044] In other words, the auto repair module 112 employs a multi phasesapproach to automatically repair the plurality of vulnerable source code programfragments and replaces with safe source code program fragments. As shown in FIG.2, the auto repair module112 operates on source code of the application in binaryform. It uses the mapping generated by the mapping creation module from thevulnerable source code program fragments to its corresponding source codeprogram fragments. The auto repairing module operates on a path capturingapplication functionality as computed by a functionality determination module. Thepath contains vulnerable source code program fragments to be repaired. A keybenefit of operating over the path is to provide a direction and a terminationcriterion for auto repair process.

[045] The step 208 is better understood by way of the followingdescription provided as exemplary explanation.

[046] The functionality determination module extracts a functionalityfrom the application in binary form using a plurality of functional ordered autorepair rules before executing an auto repair strategy. The functionality is extractedin form of a path that starts with a program statement and ends with a programstatement. The path might run across multiple procedures. A functional orderedauto repair rule comprises two attributes among a plurality of attributes that helpextracts functionality. First attribute 'functionalgroup' denotes the name offunctionality to which functional ordered auto repair rule belongs. The nameattribute categorizes all functional ordered auto repair rules into different categories(also referred as functionality aspect). Second attribute is order, the value of whichdetermines order of execution of a program statement in a path. A functionalordered auto repair rule for remove strategy is further better understood by way offollowing pseudocode provided as example:public FunctionalOrderRule(){id = "KeyPair";methodName = "generateKeyPair";className = "java.security.KeyPairGenerator";argCount = θ;methodType = virtualMethod;updateStrategy = update_strategy_remove;functionalgroup = "Generation of Crypto Keys";order = "3";}It is shown in the above pseudocode, the functional ordered auto repair rule forremove strategy has functionalgroup and order attributes. Former attributedescribes that the rule belongs to a functionality of program statements capturingcryptographic key pair generation and later attribute describes an order in which aprogram statement that invokes the virtual method generateKeyPair will appear inan application path.

[047] In an embodiment, all functional ordered auto repair rules belongingto a particular functional group are extracted. The rules are sorted based on valueof order attribute. For every procedure and its program statements, the functionalordered auto repair rules are executed to determine their applicability. If afunctional ordered auto repair rule is applicable to a program statement, then, theprogram statement is annotated with a value of order attribute. The procedure towhich the program statement belongs to is also annotated with the value of orderattribute and the value of functionalgroup attribute that describes the functionality.Further, all annotated procedures are categorized into different functional groupsbased on values of functionalgroup attribute. A procedure may belong to more thanone functional group category. For each functional group category, the methods arearranged in a call order based on the values of order attribute. For example, if amethod Y has program statements with values of order < 2 > < 3 > < 4 > and amethod X has a program statement with value of order attribute < 1 > then, in acall order X precedes Y irrespective of how they are going to be called during theexecution of application. Once all methods belonging to a functional group categoryare placed in call order, a path is generated by combining all annotated nodes as perthe call order. The path captures the entire functionality by expanding it to includeall other program statements which are not in the path as per the plurality offunctional ordered rules but they are either predecessors or successors of programstatements occurring between start and end program statements.

[048] In an embodiment, a multi phases approach is used by the auto repairmodule 112 to automatically repair the plurality of vulnerable source code programfragments and replaces with safe source code program fragments. The first phaseof the auto repair module 112 performs intra procedure analysis. It uses the pluralityof functional order auto repair rules to repair the plurality of vulnerable source codeprogram fragments and update them with the plurality safe source code programfragments.

[049] The steps executed by the first phase of auto repair module 112 areas follows:For each vulnerable program statements ps from the plurality of vulnerableprogram statements for each vulnerable source code program fragment from theplurality of vulnerable source code program fragments in procedure q, perform:INTRA_REPAIR_Step 1: If ps is definition statement,ps_fwd_slice = compute_intra_forward_slice (ps)save (ps, ps_fwd_slice)INTRA_REPAIR_Step 2: For each functional ordered auto repair rule from theplurality of functional ordered auto repair rules, if rule_i is applicable to ps,mark rule_iINTRA_REPAIR_Step 3: if rule_i is marked,rule_type = Extract_rule_type (rule_i)INTRA_REPAIR_Step 4: If rule_type = remove,Remove_program_statement (ps)INTRA_REPAIR_Step 5: If rule_type = update_parameters_valuesChange_parameter_values (ps)INTRA_REPAIR_Step 6: If rule_type = replaceReplace_program_statement (ps, s_ps)Save (ps, s_ps)In an embodiment, INTRA_REPAIR Steps 1-6 are executed on every procedurecontaining the plurality of vulnerable program statements. First step checks the typeof the vulnerable program statement ps. If it is a definition statement then, a forwardintra procedure slice is computed for it and stored in program statement repository.In the second step, all of the plurality of functional ordered auto repair rules areexecuted against the program statement ps and an applicable rule (rule_i) ismarked. Third step extracts the type of the matched rule (rule_i). INTRA_REPAIRSteps 4-6 execute the one or more repair strategies based on the rule type of thematched rule (rule_i) . For example, if the type of the matched rule (rule_i) isremove then, the vulnerable program statement ps is removed from source code. Ifthe type of the matched rule (rule_i) is update parameter values then, values ofparameters which are passed to the method of ps are updated with parametersvalues specified in the rule_i. If the type of the matched rule (rule_i) is replace then,the vulnerable program statement ps is replaced with a safe program statement s_psand the pair is saved in program statement repository.

[050] FIGS. 4A and 4B depict two sample codes taken from a sampleapplication for key generation and encryption functions for auto repairingvulnerable code program fragments of a software, in accordance with someembodiments of the present disclosure. FIG. 4A depict a sample code taken from asample application for key generation and encryption functions which is vulnerableto a quantum attack (i.e., a quantum computer can break the encryption scheme).FIG. 4B depict a sample code taken from a sample application for key generationand encryption functions which is a quantum safe code. Key generation andencryption functions are parts of different functions in the application in binaryform. Key generation functions in both snippets shown in FIGS. 4A and 4Bgenerate two keys: private key and public key. In the encryption functions, thegenerated keys are utilized to encrypt input data. To convert the key generationfunction of FIG. 4A (i.e., quantum unsafe code) into the key generation function ofFIG. 4B (i.e., quantum safe code), INTRA_REPAIR Steps 1-6 are applied with thetypes of the plurality of functional ordered auto repair rules being executed in thefollowing order: replace, remove, remove, remove, replace, and replace. These arereferred as the one or more repair strategies. Similarly, INTRA_REPAIR Steps 1-6 repair the encryption function.

[051] However, the INTRA_REPAIR Steps 1-6 executed for procedure qmay lead to errors in source code of the application in binary form. For example, iftype of the functional ordered auto repair rule is 'replace' then, replacing existingvulnerable program statement may lead to undefined variable errors in otherprogram statements in the procedure q. To correct such errors, the auto repairmodule 112 makes use of slice computed in the INTRA_REPAIR Step 1. Thus, theauto repair module 112 executes the following error correction steps:INTR_ERR_CORR_Step 1: ps = get_original_statement(s_ps)INTR_ERR_CORR_Step 2: ps_fwd_slice = extract_slice(ps)INTR_ERR_CORR_Step 3: If ps is a definition statement and applied_rule =replaceoriginal_variable = get_variable(ps)safe_replace_variable = get_variable(s_ps)for each variable v used in a slice node,if slice node != callsite and variable v name matches with original_variablereplace_variable(v, safe_replace_variable)INTR_ERR_CORR_Step 4: If ps is a definition statement and applied_rule =removeoriginal_variable = get_variable(ps)for each variable v used in a slice node,if slice node != callsite and variable v name matches with original_variableremove_variable(v)In an embodiment, INTR_ERR_CORR Steps 1-4 address the one or moreinconsistency generated within a procedure (also referred as the set of vulnerabilitylocated procedures) in variable names which arise due to one or more repairstrategies adopted in Steps 1-6. However, this approach does not addressinterprocedural syntax and semantics inconsistencies. For example,INTR_ERR_CORR Step 1 checks the type of program statement ps and appliedrule and executes subsequent steps only if applied rule type is 'replace'. However,there may be another scenario where the applied rule type is 'remove'. In thatscenario, in all nodes of slice where the variable being defined by ps is used willbe removed as well. If one of slice nodes happen to be a callsite (a methodinvocation statement) which accepts the variable defined by ps as one of itsarguments then, the corresponding argument is removed as well. This causeschanges in declaration and definition of a procedure corresponding to that callsite.To handle such cases, intra procedure repair is not sufficient and an inter procedureanalysis of auto repair strategy should be devised. INTR_ERR_CORR Steps 3 and4 are updated to handle scenarios wherein a slice contains callsite node (a methodinvocation statement). Both steps make additional check of callsite node on a pathcomputed by the functionality determination module. The updatedINTR_ERR_CORR Steps 3 and 4 are provided below:INTR_ERR_CORR_SLICE Step 3:if ps is a definition statement and applied_rule = replace,original_variable = get_variable(ps)safe_replace_variable = get_variable(s_ps)for each variable v used in a slice node,if slice node != callsiteif variable v name matches with original_variablereplace_variable(v, safe_replace_variable)elseif slice node is on app_func_pathif variable v name matches with original_variablem = get_procedure_for_callsitemark mif type(original_variable) != type(safe_replace_variable)update_procedure_declaration(m)INTR_ERR_CORR_SLICE Step 4:if ps is a definition statement and applied_rule = removeoriginal_variable = get_variable(ps)for each variable v used in a slice nodeif slice node != callsiteif variable v name matches with original_variableremove_variable(v)elseif slice node is on app_func_pathm = get_procedure_for_callsitemark mupdate_procedure_declaration(m)the updated INTR_ERR_CORR_SLICE Steps 3 and 4 handle scenarios when aslice contains callsite. If the type of applied rule is 'replace' and slice node is'callsite' then, step 3 fetches procedure m for that callsite and update its declaration.Typically, changes made to method declaration include changing name of argumentcorresponding to original definition of program statement ps in callsite andchanging type of variable in method declaration m. Procedure m is marked as wellfor subsequent processing. Step 4 handles the case when the type of applied rule isremove. Step 4 fetches the procedure m corresponding to callsite and updates itsdeclaration. Typically, changes made to method declaration include removingactual argument from the callsite corresponding to original variable defined byprogram statement ps and formal parameter from method declarationcorresponding to actual argument.

[052] In an embodiment, the updated INTR_ERR_CORR_SLICE Steps 3and 4 mark procedures corresponding to callsites and update method declarationsas well. These changes give rise to syntax and semantic inconsistencies in updatedmethods. The following steps address newly introduced inconsistencies in otherprocedures (also referred as the set of non-vulnerability located procedures) tocomplete the auto repair process:INTER_ERR_CORR Step 1:m = get_marked_procedureunmark mINTER_ERR_CORR Step 2:if type_of_change = remove_parameterparameter_variable = get_removed_parameterslice = forward_slice (parameter_variable)for every node n in sliceif n != callsiteif n contains parameter_variableremove_parameter_variable (n)elseif n is on app_func_pathm' = get_procedure_for_callsitemark m'update_method_declaration (m')INTER_ERR_CORR Step 3:if type_of_change = replace_parameterparameter_variable = get_replaced_parameterslice = forward_slice (parameter_variable)for every node n in sliceif n != callsiteif n contains parameter_variableupdate_parameter_variable_information(n)elseif n is on app_func_pathm' = get_procedure_for_callsitemark m'update_method_declaration(m')INTER_ERR_CORR Steps 2 and 3 handle two different scenarios. If update doneto a method declaration was to remove a method parameter, then, step 2 accordinglyremoves that variable from all program statements of procedure definitionsincluding callsite. All affected program statements are computed using intraprocedure slice. If update done to a method declaration was to update a methodparameter, then, step 3 updates the type of variable in slice nodes where it is beingexplicitly checked or used. It is noted that INTR_ERR_CORR_SLICE steps 3 and4 and inter-procedure INTER_ERR_CORR steps work in iterative fashion topropagate changes throughout all affected procedures of input application.Moreover, they make additional check of callsite node which is on a path computedby the functionality determination module.

[053] In an embodiment, the key generation function as shown in FIG. 4Ais auto repaired and converted into quantum safe form as shown in FIG. 4B, and itsimpact on the encryption function as shown in FIG. 4B should be handled as well.Types of objects which are created for public and private keys are different andhence the declaration of variables is auto repaired. Moreover, the parameters passedto the encryption function as shown in FIG. 4B are auto repaired as per new typesof private and public keys. Inter procedural auto repair stepsINTR_ERR_CORR_SLICE steps 3 and 4 and INTER_ERR_CORR steps 2 and 3handle this scenario.

[054] The written description describes the subject matter herein to enableany person skilled in the art to make and use the embodiments. The scope of thesubject matter embodiments is defined herein and may include other modificationsthat occur to those skilled in the art. Such other modifications are intended to bewithin the scope of the present disclosure if they have similar elements that do notdiffer from the literal language of the embodiments or if they include equivalentelements with insubstantial differences from the literal language of theembodiments described herein.

[055] It is to be understood that the scope of the protection is extended tosuch a program and in addition to a computer-readable means having a messagetherein; such computer-readable storage means contain program-code means forimplementation of one or more steps of the method, when the program runs on aserver or mobile device or any suitable programmable device. The hardware devicecan be any kind of device which can be programmed including e.g., any kind ofcomputer like a server or a personal computer, or the like, or any combinationthereof. The device may also include means which could be e.g., hardware meanslike e.g., an application-specific integrated circuit (ASIC), a field-programmablegate array (FPGA), or a combination of hardware and software means, e.g., an ASICand an FPGA, or at least one microprocessor and at least one memory with softwareprocessing components located therein. Thus, the means can include both hardwaremeans and software means. The method embodiments described herein could beimplemented in hardware and software. The device may also include softwaremeans. Alternatively, the embodiments may be implemented on different hardwaredevices, e.g., using a plurality of CPUs.

[056] The embodiments herein can comprise hardware and softwareelements. The embodiments that are implemented in software include but are notlimited to, firmware, resident software, microcode, etc. The functions performed byvarious components described herein may be implemented in other components orcombinations of other components. For the purposes of this description, acomputer-usable or computer readable medium can be any apparatus that cancomprise, store, communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.

[057] The illustrated steps are set out to explain the exemplaryembodiments shown, and it should be anticipated that ongoing technologicaldevelopment will change the manner in which particular functions are performed.These examples are presented herein for purposes of illustration, and not limitation.Further, the boundaries of the functional building blocks have been arbitrarilydefined herein for the convenience of the description. Alternative boundaries canbe defined so long as the specified functions and relationships thereof areappropriately performed. Alternatives (including equivalents, extensions,variations, deviations, etc., of those described herein) will be apparent to personsskilled in the relevant art(s) based on the teachings contained herein. Suchalternatives fall within the scope of the disclosed embodiments. Also, the words"comprising," "having," "containing," and "including," and other similar forms areintended to be equivalent in meaning and be open ended in that an item or itemsfollowing any one of these words is not meant to be an exhaustive listing of suchitem or items, or meant to be limited to only the listed item or items. It must also benoted that as used herein, the singular forms "a," "an," and "the" include pluralreferences unless the context clearly dictates otherwise.

[058] Furthermore, one or more computer-readable storage media may beutilized in implementing embodiments consistent with the present disclosure. Acomputer-readable storage medium refers to any type of physical memory on whichinformation or data readable by a processor may be stored. Thus, a computerreadablestorage medium may store instructions for execution by one or moreprocessors, including instructions for causing the processor(s) to perform steps orstages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and excludecarrier waves and transient signals, i.e., be non-transitory. Examples includerandom access memory (RAM), read-only memory (ROM), volatile memory,nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and anyother known physical storage media.

[059] It is intended that the disclosure and examples be considered asexemplary only, with a true scope of disclosed embodiments being indicated hereinby the following claims.

Claims

1. A processor implemented method (200), comprising: receiving (202), via an input / output interface, an application in binary form, and a set of predefined vulnerability detection rules as an input; detecting (204), via a first module executed by one or more hardware processors, a plurality of vulnerable program fragments in the received application in binary form based on the set of predefined vulnerability detection rules; creating (206), via a second module executed by the one or more hardware processors, a mapping between the application in binary form and a plurality of source code files corresponding to the application in binary form to identify a plurality of vulnerable source code program fragments; and performing (208), via a third module executed by the one or more hardware processors, an auto repairing process on each of the identified plurality of vulnerable source code program fragments to obtain a plurality of safe source code program fragments, wherein the auto repairing process comprises: extracting, one or more paths representing a functionality aspect of the application in binary form and a plurality of vulnerable program statements for each vulnerable source code program fragment from the plurality of vulnerable source code program fragments in the application in binary form based on the created mapping; applying, a functional ordered auto repair rule from a plurality of functional ordered auto repair rules in accordance with a plurality of predefined criterions to each of the plurality of vulnerable program statements of each path from the one or more paths; computing, an effect of applying the functional ordered auto repair rule on a plurality of non-vulnerable program statements within a first set of procedures from a set of procedures associated with each of the one or more paths, wherein the functional ordered auto repair rule utilizes one or more repair strategies, and wherein one or more inconsistencies are generated in the plurality of nonvulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths when the one or more repair strategies are used; resolving, the one or more inconsistency generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths; and iteratively computing, an effect of use of the one or more repair strategies on a second set of the procedures from the set of procedures and resolving the one or more inconsistency generated in the second set of procedures from the set of procedures associated with each of the one or more paths.

2. The processor implemented method as claimed in claim 1, wherein the functionality aspect is characterized by a functional group attribute and an order attribute.

3. The processor implemented method as claimed in claim 1, wherein the plurality of predefined criterions include (i) determining type of each of the plurality of vulnerable program statements (ii) determining a functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements, and (iii) determining a rule type of the functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements.

4. The processor implemented method as claimed in claim 1, wherein the first set of procedures represents a set of vulnerability located procedures.

5. The processor implemented method as claimed in claim 1, wherein the second set of procedures represents a set of non-vulnerability located procedures.

6. The processor implemented method as claimed in claim 1, wherein the one or more repair strategies are utilized based on the rule type of the functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements7. A system (100), comprising: a memory (102) storing instructions; one or more communication interfaces (106); and one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to: receive, an application in binary form and a set of predefined vulnerability detection rules as an input; detect, a plurality of vulnerable program fragments in the received application in binary form based on the set of predefined vulnerability detection rules; create, a mapping between the application in binary form and a plurality of source code files corresponding to the application in binary form to identify a plurality of vulnerable source code program fragments; and perform, an auto repairing process on each of the identified plurality of vulnerable source code program fragments to obtain a plurality of safe source code program fragments, wherein the auto repairing process comprises: extracting, one or more paths representing a functionality aspect of the application in binary form and a plurality of vulnerable program statements for each vulnerable source code program fragment from the plurality of vulnerable source code program fragments in the application in binary form based on the created mapping; applying, a functional ordered auto repair rule from a plurality of functional ordered auto repair rules in accordance with a plurality of predefined criterions to each of the plurality of vulnerable program statements of each path from the one or more paths; computing, an effect of applying the functional ordered auto repair rule on a plurality of non-vulnerable program statements within a first set of procedures from a set of procedures associated with each of the one or more paths, wherein the functional ordered auto repair rule utilizes one or more repair strategies, and wherein one or more inconsistencies are generated in the plurality of nonvulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths when the one or more repair strategies are used; resolving, the one or more inconsistency generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths; and iteratively computing, an effect of use of the one or more repair strategies on a second set of the procedures from the set of procedures and resolving the one or more inconsistency generated in the second set of procedures from the set of procedures associated with each of the one or more paths.

8. The system as claimed in claim 7, wherein the functionality aspect is characterized by a functional group attribute and an order attribute.

9. The system as claimed in claim 7, wherein the plurality of predefined criterions include (i) determining type of each of the plurality of vulnerable program statements (ii) determining a functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements, and (iii) determining a rule type of the functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements.

10. The system as claimed in claim 7, wherein the first set of procedures represents a set of vulnerability located procedures.

11. The system as claimed in claim 7, wherein the second set of procedures represents a set of non-vulnerability located procedures.

12. The system as claimed in claim 7, wherein the one or more repair strategies are utilized based on the rule type of the functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements.