@gnyman@infosec.exchange No kidding? I can only recommend anyone doing research on N-Able to avoid going through their "bug bounty" program. They actively cite the program rules to shut down disclosure, namely I cannot show how trivial the attack is to pull off by using mitmproxy. So there is no way for me to challenge their obviously flawed scoring of the vulnerability.
@kbal@fedia.io My first system had 128KB (64KB + banking for the rest), but using C there wasn't really an option. When I really started to write C more it was on a 1MB system. But depending on situation the acceptable stack usage can indeed be much smaller.
Also, I was a bit lazy myself and used the original buffer size. Even neater solution would allocate exactly the required memory space from heap instead.
"When you are transferring large amounts over long distance links, do limit yourself to off hours. When working between the USA and Finland, try it after 4 PM OUR time ( 10 AM Eastern USA time.) And remember that we wake up 10 hours before California. We are at time zone `UTC +2h' and in summer 'UTC +3h'"
We recently switched off_t from 32-bit to 64-bit. Once this change was made, suddenly the "ar" tool would start to generate corrupt archives when objects were deleted from the archive.
It took quite a long time to find out that this snippet in the open function was the root cause:
if (!error && (mode & O_TRUNC))
{
syscall(SYS_ftruncate, fd, 0);
Needless to say, ftruncate was getting a very large length argument passed to it, resulting in the underlying filesystem outright refusing to perform any action -> O_TRUNC would not truncate existing files -> ar generated a corrupt archive when the file shrank.
It's obvious now, but believe me it wasn't easy to find it.
This issue was made possible by a misconfiguration whereas "AllowOverride none" was used by accident. That made it possible to read the configuration file even though .htaccess file preventing it is in place.
So this in part this specific issue was a mistake by the admin (read: myself). I think it still highlights an issue that could occur in many other ways as well. It is best to restrict network access to servers when upgrading them.
PS: If you can't do things right at least make it possible for others to learn from your mistakes. 🙂
The code originally made a copy of a struct before modifying the copy. The original was then used afterwards. I entirely missed the later use and that it was critical that the original struct was used as is. So I passed a subtly modified struct to the later processing, which, in combination with a second bug I had introduced some time earlier, caused all kinds of havoc.
There was another bug I also introduced, which funnily had similar effects. This bug was added months ago, and it affected only older OS versions. I typically only run the bleeding version during development (but I had tested the change with older versions, too). Unfortunately, this issue was random as it depended on stack contents to get triggered, and thus went unnoticed until the additional scrutiny introduced this intense debugging session.
The combination of these factors made this highly frustrating thing to debug, as any kind of A-B testing fails when you have multiple or random issues.
@CrashNBurns@infosec.exchange Ooof. I wonder if it's available in some states though, for example California? They have https://oag.ca.gov/privacy/ccpa
@HardlyWorgen@mstdn.party Sure, those methods might work for now. But if Microsoft follows their reasoning ("We’re removing X from the build to enhance security and user experience of Windows 11. This change ensures that all users exit setup with internet connectivity and a Microsoft Account.") they will remove these methods eventually as well.
The httpget 0.2 doesn't quite work in the form it was uploaded.
First it uses hardcoded argv, argc instead of getting from the app invocation (as args in main, the code uses void main).
Second obtaining any data from the socket will result in the app stopping and leaving behind an empty file (if (nread) break;).
This program could never download anything. It is likely some work in progress or modified test version of httpget. Since it includes some windows specific headers and has disabled the unix ones I can only presume it was some earlier attempt to get the tool running on windows.
So while the code has a local stack buffer overflow it can't be triggered for this early version.
@gnyman@infosec.exchange No kidding? I can only recommend anyone doing research on N-Able to avoid going through their "bug bounty" program. They actively cite the program rules to shut down disclosure, namely I cannot show how trivial the attack is to pull off by using mitmproxy. So there is no way for me to challenge their obviously flawed scoring of the vulnerability.
ref https://infosec.exchange/@harrysintonen/112999715864274188
@kbal@fedia.io My first system had 128KB (64KB + banking for the rest), but using C there wasn't really an option. When I really started to write C more it was on a 1MB system. But depending on situation the acceptable stack usage can indeed be much smaller.
Yes, I am aware that is libmpdec code really.
Also, I was a bit lazy myself and used the original buffer size. Even neater solution would allocate exactly the required memory space from heap instead.
Good to remember:
"When you are transferring large amounts over long distance links, do limit yourself to off hours. When working between the USA and Finland, try it after 4 PM OUR time ( 10 AM Eastern USA time.) And remember that we wake up 10 hours before California. We are at time zone `UTC +2h' and in summer 'UTC +3h'"
So what was the bug I was looking for?
We recently switched off_t from 32-bit to 64-bit. Once this change was made, suddenly the "ar" tool would start to generate corrupt archives when objects were deleted from the archive.
It took quite a long time to find out that this snippet in the open function was the root cause:
if (!error && (mode & O_TRUNC))
{
syscall(SYS_ftruncate, fd, 0);
Needless to say, ftruncate was getting a very large length argument passed to it, resulting in the underlying filesystem outright refusing to perform any action -> O_TRUNC would not truncate existing files -> ar generated a corrupt archive when the file shrank.
It's obvious now, but believe me it wasn't easy to find it.
#bugstories
Post mortem:
This issue was made possible by a misconfiguration whereas "AllowOverride none" was used by accident. That made it possible to read the configuration file even though .htaccess file preventing it is in place.
So this in part this specific issue was a mistake by the admin (read: myself). I think it still highlights an issue that could occur in many other ways as well. It is best to restrict network access to servers when upgrading them.
PS: If you can't do things right at least make it possible for others to learn from your mistakes. 🙂
@phf@mastodon.de Their servers have been quite fragile today. It's coming and going.
Here's the more constructive part of the (I still think warranted - but likely a bit tone deaf) rant: https://github.com/tukaani-project/xz/pull/181
@gnyman@infosec.exchange I had the following enabled for me:
I had specifically disabled "Item-level purchase data" before, and I'm fairly confident I did not explicitly enable those other two.
@Alexstarfire@lemmy.world I sure did. I also renamed the variable to a name that makes its existence obvious to anyone reading the code.
The code originally made a copy of a struct before modifying the copy. The original was then used afterwards. I entirely missed the later use and that it was critical that the original struct was used as is. So I passed a subtly modified struct to the later processing, which, in combination with a second bug I had introduced some time earlier, caused all kinds of havoc.
There was another bug I also introduced, which funnily had similar effects. This bug was added months ago, and it affected only older OS versions. I typically only run the bleeding version during development (but I had tested the change with older versions, too). Unfortunately, this issue was random as it depended on stack contents to get triggered, and thus went unnoticed until the additional scrutiny introduced this intense debugging session.
The combination of these factors made this highly frustrating thing to debug, as any kind of A-B testing fails when you have multiple or random issues.
#bugstories
@kbal@fedia.io "Nice flow you've going there, would be a shame if I had to reboot"
@CrashNBurns@infosec.exchange Ooof. I wonder if it's available in some states though, for example California? They have https://oag.ca.gov/privacy/ccpa
This here is the prime example of why we must stay vigilant about the collection and dissemination of personal information.
Also, while this article only mentions "algorithm", it's not difficult to predict that AI models are or will be used for this kind of task.
AI advocates often claim that any plans to regulate AI are just a hindrance to progress. I will take regulation if it will stop this kind of madness.
@HardlyWorgen@mstdn.party Sure, those methods might work for now. But if Microsoft follows their reasoning ("We’re removing X from the build to enhance security and user experience of Windows 11. This change ensures that all users exit setup with internet connectivity and a Microsoft Account.") they will remove these methods eventually as well.
@infinity Yeah, it does for now. I fully expect Microsoft to remove that registry key or the associated functionality next.
After all not doing so would mean that users could accidentally setup the system "without working internet connectivity and a Microsoft Account".
That would be terrible for security and user experience *cough* business.
@jerry It largely depends on how well the initial impact is cleaned up. I'm hoping we won't see a ton of backdoors in various components next.
The httpget 0.2 doesn't quite work in the form it was uploaded.
First it uses hardcoded argv, argc instead of getting from the app invocation (as args in main, the code uses void main).
Second obtaining any data from the socket will result in the app stopping and leaving behind an empty file (if (nread) break;).
This program could never download anything. It is likely some work in progress or modified test version of httpget. Since it includes some windows specific headers and has disabled the unix ones I can only presume it was some earlier attempt to get the tool running on windows.
So while the code has a local stack buffer overflow it can't be triggered for this early version.
"#Nordnet admits that it was possible to trade in other people's depots during the IT breakdown"
https://www.marketscreener.com/quote/stock/NORDNET-AB-115787339/news/Nordnet-admits-that-it-was-possible-to-trade-in-other-people-s-depots-during-the-IT-breakdown-49034492/
#Nordnet services appear to be back.