This is where I put all the things I've created which I hope may somehow be useful to others.
I believe in modular, purpose-built software. The more freely a program or library can be adapted and joined to other software the better. This of course begs the question of interoperability, documentation and cooperation amongst developers, and is why I am a sharp proponent of free software. I cannot stress how important it is, not simply just for myself (in that regard I find it to be an unparalleled educational tool), but rather for humanity as a whole. It is the actualization of creating software without constraints of intellectual ownership/micromanagement.
I have a strong interest in distributed software systems, especially favoring self-healing networks and distributed data structures and associated techniques. Beyond that I prefer to create purpose-built, practical use applications in a variety of languages. Practical in that their sole use isn't to pad a resume, but rather be of some use to others now and in the future beyond direct use even, either for design ideas or coding practices. Being able to riddle off a list of intangibles for the sole purpose of creating a list reeks of convenience, if nothing else. Above all else, I would hope what I have created can be of some use to people, even if only pedagogical.
In retrospect, I have since come to understand that I am a very design-driven developer, perhaps even over designing at times. A vast majority of my effort is prepaid out beforehand designing multiple approaches and ideas. Generally this pays off since perfect information about the task at hand rarely exists (so much for SCRUM), and I'd rather fall back on a secondary design than have to re-design again on the fly. Over-designing also helps the implementation in terms of knowing what you'll expect out of certain parts of the program. Despite modern languages offering an over-abundance of higher-order constructs, I honestly don't believe in their liberal use, ie. Php's magic methods. Most of the highly extrapolated capabilities of modern languages are more reliably implemented by means of lower level controls. Illustratively, one could implement an alternative, and more highly-tailored form of reflection in any language that doesn't support it by means of status accessor methods. Judgment calls will inescapably need to be made about any design decision and in some cases these constructs can be indispensable, however a rush to be highly reflexive/dynamic isn't always the best approach, as readability can suffer.
uTorrent 2.2.1's API issue assesment
The following is the evaluation and posture assesment for a vulnerability disclosed by Tavis Ormandy and Google's Project Zero.
The Bug "recently" found/disclosed in early 2018. Could there actually exist a crude API endpoint in the client which would allow the system to be probed unattended!?
For the entire evaluation of this I'll assume a client version of v2.2.1 as anything later than that is garbage, and for obvious reasons. Aparently in the later versions the amount of endpoints seem have been expanded, which of course allows for more potential trouble as well.
The cornerstone to this vulnerability is the realization that in an unfiltered browser (one without a script blocker or application boundary enforcer (ABE)) you can't be sure of what the delivered js is doing. In reality it could in the worst case compromise the integrity of the application and/or at least attempt to do things unbeknownst to the user. This vector, even with v2.2.1 is possible.
The altering of the setting "net.discoverable" to false only closes the predictable port (TCP:10000) where the api listens. This helps lessen the attack surface for web drive-bys by requiring any script to at the very least scan the port space for a service responding with "invalid request". In addition to this port though, there is another way to the API 0.0.0.0:PORT, which turns out to be a on the TCP port of the same number that the client is using to orchestrate the udp torrent protocol traffic on.
This is quite unfortunate as anyone who can see the traffic flow can attempt to access the api via this obvious pairing.
The critical aspect, however, lies in the realization that almost every practical instance of the use of the application will involve a NAT router at least once somewhere upstream. This is certainly true of any use in a home setting and in almost everywhere except for perhaps a data center or rented box with public address. What this will prevent is the forwarding of SYN requests to the global listening instance on 0.0.0.0:PORT I have actually tested this out and have observed zero inbound requests over several weeks of observations and attempts to probe from either side. This means that, as long as the NAT is not being altered to manually allow a port-forward or honoring uPnP (which should absolutely be disabled) then the liklihood of traffic ever reaching it is inconsequential. The website drive-by is however still a valid concern and is enough to warrant the abandonment of the application.
Moreover the use of such an api (especially in later versions) and unclear purpose should be explained and at least allowed to be disabled wholesale as it doesn't appear to be a valid/necessary part of the torrent protocol. If such a "local" messaging system is still needed another approach should be used.
At least this should lead some insight as to the liklihood of an unattended system takeover. Where the application is behind a NAT, there is less of a concern, however NAT should definately not be seen as a valid form of protection, rather propper application design is paramount.
Lastly, I did witness utorrent attempting to reach the pub-address:PORT for the api periodically as some sort of connectivity test. The flow would always fail to synchronize as the NAT lacked an entry back to the true origin, as one would expect. No inbound SYNs were ever witnessed trying to reach the local application from the outside so it does not appear to be a critical part of the torrent protocol as normal peer activity still happened completely unabated.
Links:
So in closing, while there are definately concerns about the uTorrent v3.X line containing a remotely reachable api server without any access restrictions which can be also reached via scripts while browsing without noscript (or equivalents), the assumptions made by the initial researcher may or may not entirely implicate what has or hasn't been a weakness for the venerable v2.2.1 line. Out of the box none of the suspect URLs crash the older variant (my own testing and others) and many of the more advanced endpoints don't exist for it as well. Nevertheless, the existence of an RPC endpoiont sitting on the TCP port of the same number as the UDP bittorrent negotiation port is unacceptable. If for no other reason than it is an unnecessary, undocumented, proprietary interaction mechanism. Additionally, It is something that, if you were running the client on a public address, would completely open the endpoint up to anyone who is willing to probe it. The reality of this is not, again, straightforward as almost eveyone runs behind NAT, and at least a sensible NAT without uPnP will not have any mappings to the open TCP api endpoint on the same port number as the UDP bittorrent protocol port. This can and has been tested by myself in the form of trying to reach the port from the outside of the NAT and also watching anything inbound on the other side (for several hours on multiple occasions). In both cases it checks out. The port isn't open on the NAT and no traffic is witnessed on the inside. This critical aspect is something absent in all discussions about the threat posturing assesments for a user's existing system with this vulnerability.
Usually, upon learing of a recently disclosed or discoverd vulnerability its extemely important for users to asses the pre-existing level of exposure they may have inadvertently been party to, irregardless of the full severity of the situation. In this case, as in others, I think theres plenty of room for variation and given that it requires many elements including network topography, browsing behavior / setup and the like, its not always immediatly beneficial to rush to the conclusion that the worst has occurred as the user may have been running a setup similar to whats described above on a machine with little to no browsing activity or where the browsing environment is well locked-down via ABE. However, dispite this its more than time to consider the application unfit, and move on as it will not be patched.