6 added 142 characters in body
source | link

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. Bigger AV vendors are also better placed to convince the vendor of the flawed software to do something about it than, no offence to you, some random person. If you can identify from press coverage any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. It might exploit your network stack, and you already downloaded it. Such is life.

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. Bigger AV vendors are also better placed to convince the vendor of the flawed software to do something about it than, no offence to you, some random person. If you can identify from press coverage any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. Bigger AV vendors are also better placed to convince the vendor of the flawed software to do something about it than, no offence to you, some random person. If you can identify from press coverage any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. It might exploit your network stack, and you already downloaded it. Such is life.

5 added 142 characters in body
source | link

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. Bigger AV vendors are also better placed to convince the vendor of the flawed software to do something about it than, no offence to you, some random person. If you can identify (fromfrom press coverage) any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. If you can identify (from press coverage) any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. Bigger AV vendors are also better placed to convince the vendor of the flawed software to do something about it than, no offence to you, some random person. If you can identify from press coverage any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

4 deleted 3 characters in body
source | link

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the exploitflaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. If you can identify (from press coverage) any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you in the previous step.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the exploit yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end. If you can identify (from press coverage) any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you in the previous step.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

should I stick it in my IDE, build it and then send the built version to them

That's not a good option. Unless there's some reason to believe that the malware author and you have a dev environment in common that the AV vendor cannot reasonably access, the AV vendor can do this themselves and will if they think it would help. It's highly likely they can do a better job of considering the question, "what might the released malware look like and how can we detect the full variety of malware we're likely to see attacking this flaw?" than you can, because it's squarely in their line of work.

Consider: that in your hands, since you are not malicious, this becomes proof of concept exploit code. It might have been intended to be malware, and you did not discover the flaw yourself, but leaving aside the details of credit and priority, you're in basically the same position regarding disclosure as you would be in if you had discovered the flaw yourself and written this code to prove it exploitable.

At the least you should:

  • Search for recognisable short sections of the code online to make sure this specific source code is not already published. I know you've deduced otherwise, but I can't shake the nagging feeling that maybe this is proof of concept exploit code and not malware.

  • Go through the flaw disclosure process of the vendor of the "security program" that this code exploits. If they don't have a process, email or otherwise contact them and ask. Do whatever you can within this process to convey your conclusion that a working exploit for the flaw is already in the wild.

  • If that gets no satisfactory response then go to one or more AV vendors. Find out how your chosen vendor prefers to receive malware submissions or use an existing list of contact details. Since this is a somewhat unusual case, in that you have source to submit rather than just a malicious binary, I advise leaning toward anything that looks like there might be a human on the other end.

  • Don't focus just on the AV you happen to use: if you can persuade any (major) AV vendor to recognise the issue then others including yours will follow. If you can identify (from press coverage) any security researchers who have previously discovered flaws in the same software, or software from the same vendor, include them in your list of people to contact. They have already dealt with the disclosure process that failed to satisfy you.

  • If that still gets no satisfactory response, then as an absolute last resort, submit a compiled binary version[*] of the suspected malware as above, and hope that their routine for submitted binaries does a better job than they did with the source.

[*] you've already compiled it, so the ship has sailed on any concerns that it might exploit your compiler as well as being code to exploit this security program. For that matter, it might exploit your text editor, and you already looked at it with that. Such is life.

3 added 104 characters in body
source | link
2 added 104 characters in body
source | link
1
source | link