My brain has issues with this kind of form. It prevents me from reading words in a fifo manner. I now need to backtrack, because the 'no' negates the word before.
Recently Claude and GPT have either both acquired this tic or I've become hypersensitive to it but it's just unbearable and it turns out that an editing pass which forbids "X verbs no noun" constructions will basically always improve a piece of writing. If I could only pick one construct to ban I'd probably choose it even over the classic "not X but Y".
FWIW this is exactly how you negate a verb in German. For example: "Ich rauche nicht " -> "I don't smoke" or "Ich brauche keinen Mantel" -> "I don't need a coat"
English |-n't| is also a negation that applies to what comes before. In fact I don't think you actually can put a verbal negation before the verb in English in ordinary/modern circumstances; only a few verbs can be directly negated, and if one of those isn't present, one is added (usually "do", this is called "do-support") ... and the negation goes after it.
"This is how you negate a verb" -> "This is not how you negate a verb" ('is' can be negated, the negation goes after)
"This confuses the duke" -> "This does not confuse the duke" ('confuses' wants do-support to negate it, and the negation goes after 'do'.)
You are right. However, I would argue that semantically the "do" is part of the negation.
Actually, you can do the same in German ("Ich tu nicht essen" -> "I do not eat"), but it's very colloquial and "forbidden" in writing. The proper form is "Ich esse nicht".
"No" here doesn't negate needs. It is part of a subordinate clause "no privileges". Substitute with "nothing" (literally, no thing) for the same parse.
Sometimes I have scripts that automatically assign ports starting from 30000. How would that work? Would I have to bind to port 0 multiple times until I randomly get a port in that range?
I'm not quite sure what a script assigning ports actually does, but if I need an app to bind a port in some port range, I just start binding ports starting from 30000 until it succeeds.
If it's in a script then that might be difficult, but a racy approximation could be to loop e.g. listening socat with different ports for finding the free port. (Or maybe: parse output of ss.) But if the port use is separate from the port binding, then it might still be busy once the time to rebind it comes.
I'm not sure how I'd do acceptance/E2E testing without the magic of port 0. As long as you have a way of capturing what port it ended up using (which most languages are able to out of the box more or less), parallelizing testing workloads becomes such a breeze without having to manage ports and all that jazz, just fire everything up with N parallism and let the OS figure out what the free ports are, pass the references down and stuff just works. Thanks Linux :)
> I'm not sure how I'd do acceptance/E2E testing without the magic of port 0.
Same as anything else, an explicit flag to achieve the same "just give me a port" functionality as this "magic number" does without resulting in the documented unpredictable behavior around a technically legitimate port number.
As the article points out, most if not all of the services exposed on port 0 seem to be accidental and likely resulted from people assuming this magic behavior applies everywhere instead of just to one specific API.
Yeah, obviously I'm a programmer so I'm well aware it's technically possible, it was a bit of an exaggeration to explain how much value I feel I get from it.
> most if not all of the services exposed on port 0 seem to be accidental
No program actually end up "exposed on port 0", if it's not supported it won't be able to create a listener on that port, AFAIK. Most yeah, all no. P2P software commonly leverage port 0, and other "discover<>connect" types of software. But I'd agree that it's most likely accidental if outside of those niches.
Clearly you didn't read the article, plenty of stuff is in fact exposed on actual port 0 because it's a real thing and not just a way to get whatever ephemeral port like you're using.
I have a feeling what sometimes :0 is interpreted as a 'first listening'. But Occam says what most of the time it's just 'DNAT dst port ANY to :80' or whatever, no magik.
I tried submitting this multiple times yesterday using the original title. Each submission appeared to go through without error, but the post never appeared in New or on my profile.
None of these earlier publications diminish the value of the current research. If anything, they highlight how easily lessons involving obscure protocol behaviors and edge cases can be overlooked or forgotten.
Personally, I find network stack manipulation a particularly interesting area of security research, and one that doesn't always receive the attention it deserves. There's understandably significant focus on application-layer vulnerabilities, but that emphasis can lead us to take the behavior and security of the underlying network stack for granted.
The TCP/IP stack is mature, but maturity shouldn't be confused with an absence of exploitable behavior. Between implementation differences, ambiguous specifications, legacy protocol assumptions, and unexpected interactions across layers, there are undoubtedly more edge cases, vulnerabilities, and attack surfaces worth investigating.
https://web.archive.org/web/20261106234640/https://acid.vega...
I saw the URL and immediately thought it was about Acid Pro DAW or Vegas video editor is used to use back in the early 00’s.
> And asking for port 0 needs no privileges.
My brain has issues with this kind of form. It prevents me from reading words in a fifo manner. I now need to backtrack, because the 'no' negates the word before.
Recently Claude and GPT have either both acquired this tic or I've become hypersensitive to it but it's just unbearable and it turns out that an editing pass which forbids "X verbs no noun" constructions will basically always improve a piece of writing. If I could only pick one construct to ban I'd probably choose it even over the classic "not X but Y".
FWIW this is exactly how you negate a verb in German. For example: "Ich rauche nicht " -> "I don't smoke" or "Ich brauche keinen Mantel" -> "I don't need a coat"
English |-n't| is also a negation that applies to what comes before. In fact I don't think you actually can put a verbal negation before the verb in English in ordinary/modern circumstances; only a few verbs can be directly negated, and if one of those isn't present, one is added (usually "do", this is called "do-support") ... and the negation goes after it.
"This is how you negate a verb" -> "This is not how you negate a verb" ('is' can be negated, the negation goes after)
"This confuses the duke" -> "This does not confuse the duke" ('confuses' wants do-support to negate it, and the negation goes after 'do'.)
You are right. However, I would argue that semantically the "do" is part of the negation.
Actually, you can do the same in German ("Ich tu nicht essen" -> "I do not eat"), but it's very colloquial and "forbidden" in writing. The proper form is "Ich esse nicht".
legit curious, if you read 'zero privileges' does it parse easier
It parses easier, but it's still doing extra work to negate the 'needs'.
doesn't need privileges > needs zero privileges > needs no privileges
"No" here doesn't negate needs. It is part of a subordinate clause "no privileges". Substitute with "nothing" (literally, no thing) for the same parse.
Agree.
The last one doesn't say "do not give me apples" and it surely doesn't say "do not give me a zero apples"."doesn't need any privileges" is more tokens :^)
Sometimes I have scripts that automatically assign ports starting from 30000. How would that work? Would I have to bind to port 0 multiple times until I randomly get a port in that range?
I’m not exactly sure if that’s the question, but the range can be set. Here’s the Linux solution: https://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi... FreeBSD has net.inet.ip.portrange
That might not quite fit my use case. My AI-generated scripts probably won't modify system-level configuration files to change the port range
... do you not have a say in the matter?
I'm not quite sure what a script assigning ports actually does, but if I need an app to bind a port in some port range, I just start binding ports starting from 30000 until it succeeds.
If it's in a script then that might be difficult, but a racy approximation could be to loop e.g. listening socat with different ports for finding the free port. (Or maybe: parse output of ss.) But if the port use is separate from the port binding, then it might still be busy once the time to rebind it comes.
[dead]
[dupe] https://news.ycombinator.com/item?id=50399587
I'm not sure how I'd do acceptance/E2E testing without the magic of port 0. As long as you have a way of capturing what port it ended up using (which most languages are able to out of the box more or less), parallelizing testing workloads becomes such a breeze without having to manage ports and all that jazz, just fire everything up with N parallism and let the OS figure out what the free ports are, pass the references down and stuff just works. Thanks Linux :)
> I'm not sure how I'd do acceptance/E2E testing without the magic of port 0.
Same as anything else, an explicit flag to achieve the same "just give me a port" functionality as this "magic number" does without resulting in the documented unpredictable behavior around a technically legitimate port number.
As the article points out, most if not all of the services exposed on port 0 seem to be accidental and likely resulted from people assuming this magic behavior applies everywhere instead of just to one specific API.
> Same as anything else
Yeah, obviously I'm a programmer so I'm well aware it's technically possible, it was a bit of an exaggeration to explain how much value I feel I get from it.
> most if not all of the services exposed on port 0 seem to be accidental
No program actually end up "exposed on port 0", if it's not supported it won't be able to create a listener on that port, AFAIK. Most yeah, all no. P2P software commonly leverage port 0, and other "discover<>connect" types of software. But I'd agree that it's most likely accidental if outside of those niches.
> No program actually end up "exposed on port 0"
Clearly you didn't read the article, plenty of stuff is in fact exposed on actual port 0 because it's a real thing and not just a way to get whatever ephemeral port like you're using.
And then there is OpenSSH...
Oh well.Seems hugged?
I have a feeling what sometimes :0 is interpreted as a 'first listening'. But Occam says what most of the time it's just 'DNAT dst port ANY to :80' or whatever, no magik.
[flagged]
I tried submitting this multiple times yesterday using the original title. Each submission appeared to go through without error, but the post never appeared in New or on my profile.
I was using Harmonic for Hacker News (https://play.google.com/store/apps/details?id=com.simon.harm...), so it's possible the issue was with the app rather than HN itself.
I later found a separate submission (https://news.ycombinator.com/item?id=50399587) in New that had received some votes but hadn't generated any discussion.
Regardless, this isn't the first time researchers have explored TCP port 0, and it certainly won't be the last.
A few examples from a quick Google search:
* https://www.cyber-threat-intelligence.com/publications/IFIPN...
* https://z3r0trust.medium.com/socket-programming-the-bizarre-...
* https://arxiv.org/pdf/2004.03653
None of these earlier publications diminish the value of the current research. If anything, they highlight how easily lessons involving obscure protocol behaviors and edge cases can be overlooked or forgotten.
Personally, I find network stack manipulation a particularly interesting area of security research, and one that doesn't always receive the attention it deserves. There's understandably significant focus on application-layer vulnerabilities, but that emphasis can lead us to take the behavior and security of the underlying network stack for granted.
The TCP/IP stack is mature, but maturity shouldn't be confused with an absence of exploitable behavior. Between implementation differences, ambiguous specifications, legacy protocol assumptions, and unexpected interactions across layers, there are undoubtedly more edge cases, vulnerabilities, and attack surfaces worth investigating.
[flagged]