• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 565 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TM4C129ENCPDT: Security/firewall blocks download of .exe files - please use .zip extension, or convert to .tar.gz

Brian Willoughby18
Intellectual 935 points
Part Number: TM4C129ENCPDT

Tool/software: Code Composer Studio

For security reasons, corporate firewalls do not allow web downloads or email attachments of files ending with a .exe extension. I notice that Texas Instruments is fond of creating a self-extracting Windows executable instead of a straightforward .zip or .tgz/.tbz archive. Considering that the entire modern world is focused on maintaining computer security, I recommend that Texas Instruments change this policy immediately. I can't say whether .zip is the best choice for Windows, but a .exe is a very dangerous option to ask customers to allow.

As a macOS based firmware developer who is also aware of Linux customer needs, I suggest that a .tar file with gzip or bzip2 compression would be preferred to a .zip file in any event. This also happens to avoid the .exe extension.

Please note that some corporate firewalls are actually smart enough to look inside a .tar file to see that there are .exe files inside, and still block the attachments. So, it's not enough to simply repackage the same old .exe files inside another wrapper. I recommend that the entire package be reviewed to remove insecure Windows artifacts, offering those as separate, Windows-only downloads for those customers who need them.

  • 0
    Intellectual 935 points

    By the way, I am familiar with the technique of simply renaming the self-extracting archive from .exe to .zip so that the Zip-compressed data can be expanded on systems that are not Windows compatible. However, this is not enough to get past modern security firewalls, because they can detect that the file is, indeed, a Windows executable despite the extension. There is a magic number at the start of a Windows/DOS executable of "MZ" which is easy to detect. Thus, simply renaming the self-extracting .zip archive is not a solution.

    Following up on my previous comments, I see that the TivaWare C Series packages have Windows executables in the ./tools/bin/ directory which are not useful to macOS and Linux users, and should be removed from the package and supplied separately for security reasons. Another problem directory is ./third_party/FreeRTOS/TraceCon/, where there are other executables. The TraceCon utility is probably simple enough to distribute as source, rather than an executable, which solves both security issues and supports other platforms like macOS and Linux.

  • 0 in reply to Brian Willoughby18
    TI__Guru*** 134845 points
    Hello Brian,

    Thank you for the valuable feedback on this topic. At this time I am not sure we will be able to address the concerns in any timely manner, but you do bring up many very valid points about how security has changed in recent years.

    Changing the release structure for future releases would be a fairly large undertaking (especially removing and re-releasing items from the tools folder), but I believe the points you bring up are important for us to consider and that when the time comes we will need to have a serious review of how the build and release is handled to support multiple OS as well as the latest security concerns.

    Out of curiosity, do you know of any product groups at TI who have been better at keeping up-to-date on these points? If so, our team could reach out to them to learn from. (TI is very large so while I can find out, it would take me longer than if you happen to have a good example to point me to!)
  • 0 in reply to Ralph Jacobi
    Intellectual 935 points

    Ralph Jacobi said:
    Out of curiosity, do you know of any product groups at TI who have been better at keeping up-to-date on these points? If so, our team could reach out to them to learn from. (TI is very large so while I can find out, it would take me longer than if you happen to have a good example to point me to!)

    All semiconductor integrated circuit data sheets are PDF, which is cross-platform and presumably secure (although a PDF can transfer or run programs and macros).

    All documentation / literature packages, e.g. example code, is packaged in standard .zip files rather than self-extracting Windows/DOS .exe

    As for CCS and Tivaware, it seems like the other processor lines, e.g. TMS320 and MSP430, also have the same .exe downloads. Those of us who use macOS have accepted this for at least ten years, but it's about time to modernize.

  • 0 in reply to Brian Willoughby18
    Mastermind 8695 points
    Do you check the signatures of downloads?
  • 0 in reply to Peter Borenstein
    Intellectual 935 points

    Peter Borenstein said:
    Do you check the signatures of downloads?

    Yes, I always check signatures of downloads. This is part of the task of accepting responsibility for security locally. I've installed gpg2 on each macOS system, allowing management of signatures and checking of packages.

    However, it's not possible to check the signature of a package that cannot be downloaded in the first place due to it being an executable.

    I also review all URL text, particularly the host name, before clicking on any link - something that most macOS software (browsers and PDF viewers) enables by showing the URL when hovering so that you don't have to click first to find out where the link ends up.

    Security is certainly not a convenient endeavor. In fact, security is the opposite of convenience. It's an unfortunate fact of online life.