Howboys

Members
  • Posts

    69
  • Joined

  • Last visited

Everything posted by Howboys

  1. Updated and now there's a few more vulns ("HIGH"): Description The version of Tomcat installed on the remote host is prior to 9.0.43. It is, therefore, affected by multiple vulnerabilities as referenced in the vendor advisory. - When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter=null (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed. (CVE-2020-9484) - An information disclosure vulnerability exists when responding to new h2c connection requests, Apache Tomcat versions 9.0.0.M1 to 9.0.41 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. (CVE-2021-25122) - when using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. (CVE-2021-25329) - A remote code execution vulnerability via deserialization exists when using Apache Tomcat 9.0.0.M1 to 9.0.41 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. (CVE-2021-25329) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.43 or later. ----------------------- Description The version of Tomcat installed on the remote host is prior to 9.0.63. It is, therefore, affected by a vulnerability as referenced in the fixed_in_apache_tomcat_9.0.63_security-9 advisory. - The documentation of Apache Tomcat 10.1.0-M1 to 10.1.0-M14, 10.0.0-M1 to 10.0.20, 9.0.13 to 9.0.62 and 8.5.38 to 8.5.78 for the EncryptInterceptor incorrectly stated it enabled Tomcat clustering to run over an untrusted network. This was not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly DoS risks. (CVE-2022-29885) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.63 or later. ----------------------- Description The version of Tomcat installed on the remote host is prior to 9.0.40. It is, therefore, affected by multiple vulnerabilities as referenced in the fixed_in_apache_tomcat_9.0.40_security-9 advisory. - When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances. (CVE-2021-24122) - While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests. (CVE-2020-17527) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.40 or later. ----------------------- Description The version of Tomcat installed on the remote host is prior to 9.0.65. It is, therefore, affected by a vulnerability as referenced in the fixed_in_apache_tomcat_9.0.65_security-9 advisory. - In Apache Tomcat 10.1.0-M1 to 10.1.0-M16, 10.0.0-M1 to 10.0.22, 9.0.30 to 9.0.64 and 8.5.50 to 8.5.81 the Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability. (CVE-2022-34305) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.65 or later. There's more but it seems like these are still present.
  2. Just skimming https://www.samba.org/samba/docs/4.15/man-html/smb.conf.5.html, the config in OP should continue to work as in 4.12.
  3. M vulnerability scanner just popped up with this for DiskSpeed: Description According to its version, the remote web server is obsolete and no longer maintained by its vendor or provider. Lack of support implies that no new security patches for the product will be released by the vendor. As a result, it may contain security vulnerabilities. Solution Remove the web server if it is no longer needed. Otherwise, upgrade to a supported version if possible or switch to another server. Output Product : Tomcat Installed version : 8.0.53 Support ended : 2018-06-30 Supported versions : 8.5.x / 9.x / 10.x Additional information : http://tomcat.apache.org/tomcat-80-eol.html Seems like maybe it's time to upgrade Tomcat?
  4. (unrelated to this issue but) I think that might have happened because preclear on USB3 ports seems to not work properly (-110 error code as you can probably see in the diagnostics I attached above). The pre-read happens for a couple of minutes at high speeds and then the device is just disconnected. Doesn't happen on USB2 so it's not the enclosure.
  5. That's the only way? (I'll consider maybe doing preclears on my non-unraid server in the future as well)
  6. I believe that's my tailscale network ip. And I removed sdj. I can connect it through SATA but the whole point of my USB enclosure is to check disk health before I open up my server. Is there a way to make unRAID "forget" sdj?
  7. So I just got a USB enclosure to pre-clear and test drives before I put them in my unraid system. However, I have been unable to get it to work properly of late (the first 2-3 times I used it a month ago, I had no issues). I tried with a Samsung SSD first: Sep 11 11:51:56 Tower kernel: usb 4-2: new SuperSpeed USB device number 7 using xhci_hcd Sep 11 11:51:56 Tower kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Sep 11 11:51:56 Tower kernel: usb-storage 4-2:1.0: Quirks match for vid 174c pid 55aa: 400000 Sep 11 11:51:56 Tower kernel: scsi host11: usb-storage 4-2:1.0 Sep 11 11:51:57 Tower kernel: scsi 11:0:0:0: Direct-Access ASMT ASMT105x 0 PQ: 0 ANSI: 6 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: Attached scsi generic sg9 type 0 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] 937703088 512-byte logical blocks: (480 GB/447 GiB) Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Write Protect is off Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Mode Sense: 43 00 00 00 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 11 11:51:57 Tower kernel: sdj: sdj1 sdj2 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Attached SCSI disk Sep 11 11:52:06 Tower emhttpd: device /dev/sdj problem getting id And then a different SSD: Sep 11 11:56:56 Tower kernel: usb 4-2: new SuperSpeed USB device number 8 using xhci_hcd Sep 11 11:56:56 Tower kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Sep 11 11:56:56 Tower kernel: usb-storage 4-2:1.0: Quirks match for vid 174c pid 55aa: 400000 Sep 11 11:56:56 Tower kernel: scsi host11: usb-storage 4-2:1.0 Sep 11 11:56:57 Tower kernel: scsi 11:0:0:0: Direct-Access ASMT ASMT105x 0 PQ: 0 ANSI: 6 Sep 11 11:56:57 Tower kernel: sd 11:0:0:0: Attached scsi generic sg9 type 0 Sep 11 11:56:57 Tower kernel: sd 11:0:0:0: [sdj] Spinning up disk... Sep 11 11:56:58 Tower kernel: .ready Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] 488397168 512-byte logical blocks: (250 GB/233 GiB) Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Write Protect is off Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Mode Sense: 43 00 00 00 Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Attached SCSI disk Sep 11 11:57:02 Tower emhttpd: device /dev/sdj problem getting id I think the problem is that both drives are getting sdj but I'm not sure. Again, I've used this same enclosure with different drives in the past with no issues. tower-diagnostics-20220911-1157.zip
  8. Did you ever figure it out? I also can't seem to get USB 3 ports on my mobo working right with the unraid flash drive, keyboard/mouse or a USB 3 HDD enclosure. USB 2 works fine but it's soooo slow.
  9. Do i need the `/mnt/fuse/:mnt/borg` mount for the container? Fix Common Problems says borg should not exist in /mnt. These are the mounts I have:
  10. Wow didn't know about this. Alright time to tweak shutdown settings (most likely it's just a ssh session that was open from one of my remote cron jobs).
  11. Oh weird because I rebooted from the GUI. Should've been clean. tower-diagnostics-20220905-1754.zip
  12. Alright rebooting the server has worked (though it started a parity check).
  13. That's odd because the disk looks fine from smart. Here's the diagnostics. I won't reboot for a few more hours in case someone wants me to grab other logs. tower-diagnostics-20220905-0810.zip
  14. Nothing happens when I click the "Clear Stats" button.
  15. On the Main page, I see that my parity drive has 3 errors. So I can a parity check with write corrections. It did it and fixed the 3 errors. Then I ran the party check again, and this time it shows 0 errors. But the drive still shows the 3 errors on the Main page. Are these actual errors or just leftover state? How do I get rid of it?
  16. Ah that fixed it! I actually have Fix Common Problems plugin installed already but I didn't see it there (or get notified of it).
  17. If `/var/log/notify_Discord`, I see failed attempts to send notification but not actual errors or reasons why. Snippet: Mon Aug 22 06:52:01 PDT 2022 attempt 1 of 4 failed {"embeds": ["0"]} I also don't see further attempts in logs - just 1 of 4 as above for different notifications. I can do a quick test just fine: bash /boot/config/plugins/dynamix/notifications/agents/Discord.sh And I see the notification in Discord. But when I do a full test: /usr/local/emhttp/webGui/scripts/notify -e "My Event" -s "My Subject" -d "My Description" -m "My Message" -i "alert" -l "/Dashboard" I only see the notification in the UI and NOT in Discord. Here's the log for that: Mon Aug 22 07:18:13 PDT 2022 attempt 1 of 4 failed {"embeds": ["0"]} { "content": "<@1234>", "embeds": [ { "title": "My Event", "description": "My Subject", "url": "http://Tower/Dashboard", "timestamp": "2022-08-22T14:18:12.000Z", "color": "14821416", "author": { "icon_url": "https://craftassets.unraid.net/uploads/logos/un-mark-gradient@2x.png", "name": "Tower" }, "thumbnail": { "url": "https://craftassets.unraid.net/uploads/discord/notify-alert.png" }, "fields": [ { "name": "Description", "value": "My Description\n\nMy Message" }, { "name": "Priority", "value": "alert", "inline": true } ] } ] }
  18. Ah I'm dumb. "provide your personal Discord ID (it is a series of numbers, not letters)." - I was adding username + numbers ("foobar#1234") but adding just "1234" works.
  19. I'm setting up a discord server for my homelab and with unraid, I'm having some issues. And here's how I've set the Discord agent: Now, I can receive the test notifications just fine: But I'm not receiving any other notifications. I only see notifications in the unraid web ui. Even adding my tag id (the numbers) doesn't work. All I see in syslog is Aug 22 06:52:01 Tower Discord.sh: Failed sending notification Is there any way to turn up verbosity of Discord.sh or see why it failed?
  20. Version 6.10.3 2022-06-14 Repro: 1. Go to notifications settings 2. Go to the discord settings part 3. Add webhook URL 4. Apply 5. Done 6. Go back to notification settings -> Discord 7. Add tag id -> Apply Observations: All settings except "Agent function" are reset when saving tag id. It also happens if you set the tag id and webhook URL in the same step. For now, I'm just not setting the tag id.
  21. I think I may have this solved. I bought a new PSU and new RAM and when I went to replace the PSU, I noticed that my one of my current RAM sticks was not all the way seated. I also noticed that the ATX 24-pin cable was a teeny-bit loose. Anyways, after plugging them in right, my current uptime has been almost 2 days with no hiccups. If the server stays up for a few more days, I'll upgrade to a bigger case so my SATA power cables aren't pushing against the ATX port (which is what seems to be happening). Consider this solved (I'll post if I notice issues again).
  22. That's all fair and good points. I don't usually reboot often but when I'm debugging issues (which I've had lately), rebooting a few times a day is common. Yeah so best case scenario I save 20-30 seconds even if a custom image were possible so perhaps what we have is the best we'll get.